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FOREWORD 


This  report  presents  the  results  of  s  study  of  the  specifications 
for  an  information  system  Intended  to  support  the  design,  production 
and  maintenance  of  large  computer  programming  systems.  Called 
Evolutionary  System  for  Data  Processing,  or  ESDP,  it  was  begun  as  an 
internal  IBM  project  in  1965  by  the  Center  for  Exploratory  Studies 
of  the  Federal  Systems  Division  and  continued  under  Air  Force 
sponsorship  during  1967  and  early  1968. 

This  work  has  been  performed  under  contract  number  F19628-67- 
C035A  for  the  Electronic  Systems  Division,  U.S.  Air  Force  Systems 
Command.  The  project  monitor  was  Mr.  John  Goodenough,  ESLFE. 

The  authors  wish  to  express  their  appreciation  for  the  encourage¬ 
ment  and  assistance  provided  by  Dr.  John  Egan,  formerly  of  ESD,  and 
their  colleagues  Dr.  Harlan  D.  Mills  and  Mr.  Michael  Dyer. 

This  report  is  in  four  volumes:  Volume  1,  System  Description; 

Volume  2,  Control  and  Use  of  the  System;  Volume  3,  The  CAINT  Executive 
Language  and  Instruction  Generator;  and  Volume  4,  Programming  Specifica¬ 
tions.  This  report  was  submitted  on  January  31,  1968. 

This  report  has  been  reviewed  and  is  approved. 


WILLIAM  F.  HEISLER,  Col,  USAF 
Chief,  Command  Systems  Division 
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Project  Officer 
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ABSTRACT 


^SP0  is  a  propose!  system  whose  purpose  is  to  acquire, 
store,  retrieve,  publish  and  disseminate  all  documentation, 
exclusive  graphics,  concerned  with  a  large  computer 
nrogrammina  activity.  Documentation  is  deemed  to  consist,  not 
only  of  final  or  formally  published  after-the-fact  reports,  but 
of  workina  files,  desiqn  and  change  notices,  informal  drafts, 
management  reports — in  fact,  the  entire  recordable  rationale 
underlying  a  programming  system.  Maximum  attention  has  been 
concentrate!  on  the  means  of  acouiring  and  organizing 
documentation.  Two  major,  complementary  aoproach^s  rare  proposed. 
The  first  is  called  Program  Analysis  and  is  a  process  o* 
extract inq  documentation  directly  from  comoleted  programs.  The 
second  is  called  Computer  Assisted  Interrogation  and  is  a  process 
of  eliciting  information  directly  from  the  programmer,  through 
on-line  com  mu  n  icat.  ion  terminals.  The  former  provides  canonical 
data  about  the  program’s  structure.  The  latter  provides 
explanatory  material  about  all  aspects  of  the  program,  and  in  the 
absence  of  canonical  data,  may  provide  tentative  structural 
information  as  well.  The  conclusion  of  the  studv  group  is  that 
ESDP  is  a  feasible  concept  with  present-day  technology  and  that 
it  will  materially  benefit  using  organizations  in  the  production 
of  programs  *n  1  in  guiding  their  evolution  as  requirements 
change.  Tts  value  will  be  greater  for  larger  organizations, 
whose  internal  communications  difficulties  tend  to  cause  truly 
gigantic  inefficiencies.  Its  implementation  as  a  support  system 
for  such  projects  would  require  a  significant  quantum  of 
investment  in  order  to  produce  these  benefits  and  is  predicated 
on  the  use  of  a  computer  system  dedicated  solely  to  the  use  op 
ESDP. 
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INTRODUCTION  AND  SUMMARY 


1.  The  Problem  Addressed.  ESDP,  Evolutionary  System  for  Data 
Processing,  is  an  information  system  to  be  used  to  support  the 
desiqn,  implementation  and  eventual  modification  of  larqe 
computer  systems.  As  presently  conceived,  ESDP  would  be  used 
actively  to  acquire  documentation  of  programs,  data  files  and 
tests  at  three  stages:  design,  after  completion  of  the  proqrams, 
and  after  modification.  Information,  once  acquired,  is  available 
for  retrieval,  for  dissemination,  for  incorporation  in  reports, 
for  use  in  instruction  and  for  use  in  improving  subsequent 
information  acquisition  processes.  The  primary  users  of  the 
system  will  be  programmers,  whose  documentation  tasks  will  be 
lightened;  their  supervisors,  who  will  have  more  up  to  date 
information  about  program  status  than  is  normal;  systems  analysts 
who  will  bo  able  to  see  the  result  of  design  change  or  see 
programming  problems  that  force  a  desiqn  chanae;  anl  management, 
who  will  have  more  current  and  more  accurate  information  on 
progress,  manpower  utilization,  computer  utilization,  etc.  An 
instructional  subsystem  will  help  alleviate  the  inevitable 
problem  of  personnel  turnover  by  providing  instructional  material 
compiled  from  the  basic  documentation  at  little  cost  in  manpower. 

Large  programming  projects  are  characterized  by  a  truly 
staggering  problem  in  human  communication.  Management  decisions 
tend  not  to  flow  down  to  work ing- level  programmers  in  terms  most 
meaninqful  to  them:  What  do  I  have  to  do  to  my  program?  What 
help  will  I  get?  How  much  machine  time  will  be  available  next 
month?  Almost  trivial  decisions  made  by  a  programmer,  including 
implicit  decisions  not  to  do  something  (e.g.,  not  to  error-check 
an  input  item) ,  can  have  disastrous  impact  on  other  programmers. 
Design  errors  do  occur  but  the  thought  given  to  their  resolution 
is  not  always  commensurate  with  the  magnitude  of  the  nroblem. 
Trends  toward  exceeding  core  allocation  or  program  running  time 
might  not  be  recognized  until  so  late  that  massive  reprogramming 
is  needed. 


Of  all  problems,  the  one  ESDP  is  primarily  aimed  at 
solving  is  that  of  change  in  a  system.  The  problem  is  this: 
given  a  need  for  a  change  in  a  program,  how  do  we  find  what 
specific  changes  to  make,  what  else  in  the  system  will  be 
affected,  how  to  retest  the  program,  and  how  to  modify  the 
documentation. 

we  must  emphasize  that  work  on  this  project  has  been 
concentrated  on  support  of  large  programming  systems,  where  the 
formal  documentation  requirements  are  stringent,  and  the  internal 
communication  problems  overpowering.  While  many  of  the 
techniques  to  be  discussed  would  be  valid  if  applied  to  smaller 
systems,  a  system  of  the  size  and  scope  described  here  is 
intended  for  the  larger  problem.  A  short  discussion  is  given  in 
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Section  T.4  of  a  prototype  which  would  not  perform  all  functions 
but  would  be  more  economical  for  smaller  systems  and  for  further 
testinq  of  overall  concepts. 

The  ESDP  system  described  in  this  report  would  perform 
the  following  functions: 


a.  Active  acquisition  of  documentation.  The  system 
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c.  Generation  and  administration  of  instructional 
material.  ESDP  would  contain  an  instructional  subsystem  through 
which  existing  documentation  could  be  converted  into 
instructional  form  and  then  computer  assisted  instruction  courses 
administered. 


d.  Production  of  hard  copy  documents.  ESDP,  in 
addition  to  providing  a  retrieval  system,  would  produce  the 
written  documentation  usually  required  of  a  programming  project. 
No  attempt  should  be  made  to  replace  this  form  of  documentation. 
Rather,  the  traditional  form  of  documentation  would  be  augmented 
by  the  retrieval  and  instruction  systems. 

Extensions  of  the  system  can  provide  for: 

e.  Computer  assisted  test  planning  and  documentation. 

f.  Hypothesis  testing,  in  which  system  users  can 
analyze  the  consequences  of  proposed  changes  to  the  system. 


g.  Computer  assisted  programming  in  which  many 
basic  concepts  presented  here  are  used  to  provide 
assistance  in  writing  object  system  programs  (the  object 
is  the  program  system  being  documented) . 
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2.  Zll£  1:2112  I2E2  Solution.  The  solution  to  the  problems  of 
assisting  programmers  in  the  production  of  their  programs,  and  in 
providing  the  needed  communication  and  documentation,  is  to 
provide  an  information  system  with  these  features: 


o  It  should  be  a  d.222Si  Lory  for  all  record  a  bl 
information  about  the  object  system  (the  progra 
being  produced) . 


o 


o 


It  should  be  an  active  system, 
initiative  in  seeking  out 

programmers,  analysts  and 

disseminating  that  information 


It  should  take  the 
information  from 
managers  and  in 
to  all  concerned. 


It  should  be  compre hensi ve.  The  system  should 
encompass  all  the  documentation  about  the  object 
system,  although  not  necessarily  in  machine- 
readable  form. 


o  It  should  be  accessible.  Information  can  be 
gotten  from  the  system  by: 

information  retrieval  queries 

automatic  report  compilation 

automatic  dissemination 


instructional  programs. 
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a.  Acquisition 
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b.  Storage 

All  machine  readable  documentation  and  all  object 
programs  should  be  stored  as  part  of  the  ESDP  data  base.  Not  all 
this  information  need  be  continuously  on-line,  but  all  should  be 
available,  say  from  tape  or  disk  cabinets,  within  a  few  minutes 
of  the  time  it  is  requested. 

c.  Dissemination 


A  selective  dissemination  system  should  immediately 
transmit  newly  acquired  information  to  interested  readers.  User 
interest  profiles  could  be  entered  by  individuals,  management  (on 
behalf  of  others)  or  even  generated  by  FSDP.  As  an  example  of 
the  use  of  automatically-generated  interest  profiles,  assume  that 
program  A  is  modified  to  make  use  of  an  output  of  program  D, 
while  previously  there  had  been  no  connection  between  the  two. 
The  programmers  involved  should  be  automatically  added  to 
distribution  lists  for  each  other's  documentation. 

d.  Information  Retrieval 
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Under  countless  sets  of  circumstances,  system  users 
to  recover  information  immediately  from  the  ESDP  data 
information  retrieval  system  should  be  included  in  ESDP 
serve  as  an  on-line  system  responsive  to  user  queries 
Iso  serve  as  a  subsystem  of  other  ESDP  programs. 


e.  Generate  Documentation 


More  or  less  conventional,  hard  copy 
should  be  a  major  product  of  ESDP.  The  availa 
dissemination  system  and  an  on-line  retrieval 
certainly  have  some  effect  on  the  form,  content,  and 
issue  of  printed  reports.  However,  it  seems  im 
assume  that  electronic  displays  will  completely  re 
matter  in,  say,  the  next  five  to  ten  years. 
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f.  Provide  Instruction 

The  documentation  contained  in  the  ESDP  data  base 
should  be  convertible  into  instructional  materials.  A  qualified 
instruction  or  traininq  specialist  must  supervise  the  process, 
but  his  work  would  be  made  easier  by  the  ESDP  system  itself. 
Both  computer  assisted  instruction  (CAI)  courses  and  printed 
proqrammed  instruction  (PI)  texts  could  be  qenerated  by  a  similar 
process.  Instruction  courses  so  generated  would  require  far  less 
instruction  time  to  prepare  and  could  be  much  more  easily  updated 
than  convent ionally-written  CAI  or  PI  courses. 

q.  Test  Planning 

ESDP  should  actively  assist  in  the  design, 
documentation,  and  preparation  of  program  tests,  at  all  levels 
from  small  program  modules  to  large  assembly  tests.  The 
information  available  to  ESDP  about  a  program  contains  much  that 
is  useful  to  the  test  designer.  ESDP  could  assist  him  in 
planning  what  program  segments  or  modules  to  test  in  any  one  run, 
what  data  values  are  to  be  tried,  and  what  programs  or  segments 
are  independent  of  what  others,  which  information  can  be  used  to 
reduce  the  number  of  test  runs.  Finally,  the  system  should 
enable  the  test  planner  to  assemble  a  set  of  test  data.  The 
study  of  test.  planning  was  not  a  task  under  the  contract. 
However,  sufficient  interest  was  generated  to  create  an  IBM- 
sponsored  stuiy  in  the  area  to  be  undertaken  in  1968. 

h.  Hypothesis  Testing 

Related  to  the  concept  of  test  planning,  hypothesis 
testing  is  the  investigation  or  verification  of  assumptions  about 
how  the  system  performs.  The  technique  is  intended  to  bo  able  to 
provide  answers  to  questions  that  are  phrased  in  external,  or 
performance-oriented  terms,  rather  than  in  terms  of  specific 
program  threads  or  control  decisions.  It  would  be  more  for 
system  users  to  determine  how  the  programs  would  perform  in  a 
hypothetical  situation  than  for  programmers  to  test  their 
programs.  This  topic,  also,  was  not  a  part  of  the  study  just 
completed  but  is  believed  to  be  a  valid  extension  of  the  study. 

3.  Areas  of  Concentration  of  the  Study.  The  objective  of  the 
recently  concluded  study  was  to  produce  specifications  for  an 
operational  ESDP  where  the  term  "specification"  was  interpreted 
as  a  broad,  conceptual-level  description.  Because  of  the 
advanced  nature  of  the  project  not  all  areas  were  given  equal 
attention  nor  explored  to  the  same  depth.  Indeed,  tost  planning 
and  hypothesis  testing  were  conceived  as  applications  during  the 
study  but  not  pursued  as  part  of  the  study. 

Major  emphasis  was  placed  on  those  areas  which  we  felt 
were  critical  for  proving  feasibility  of  ESDP.  These  were: 

Acquisition  of  design  information 
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Acquisition  of  program  documentation 
On-line  information  retrieval 
Document  generation 
Instruction 


The  acquisition  of  design  information  is  to  be  carried 
out  by  interrogation  of  programmers,  systems  analysts  or 
managers.  It  elicits  their  design  plans  for  programs  and  data 
base  elements.  Design  interrogations  do  not  differ  in  concept 
from  interrogations  based  upon  the  existence  of  an  object  program 
but  they  would  be  based  only  on  information  collected  during 
previous  design  interrogations. 

The  acquisition  of  program  documentation  is,  by 
definition,  based  upon  the  existence  of  an  object  program.  It  is 
to  be  done  in  two  ways:  first,  by  direct  analysis  of  the  program 
to  determine  its  internal  structure,  its  interfaces  with  other 
programs,  and  its  data  usage;  second,  by  interrogation  of  the 
programmer  based  upon  data  extracted  from  his  program.  We 
repeat — this  interrogation  is  not  inherently  different  from  a 
design  interrogation  but  is  based  on  knowledge  of  the  program, 
hence  can  be  much  more  concise  and  informed. 

On-line  information  retrieval,  while  not 
was  an  object  of  attention  on  this  project  because 
integrate  retrieval  with  the  interrogation 

generation  functions. 

Documents  produced  through  ESDP  would  be  hierarchically 
organized  and  primarily  textual  in  content.  They  would  not 
simply  be  tables,  such  as  the  cross-reference  listing  produced 
with  program  compilations.  We  have  not  investigated  flow 
charting  programs  because  of  the  existence  of  several  quite 
versatile  and  effective  programs  with  which  ESDP  could  be  made  to 
interface  [1,4].  ESDP  printed  documents  are  intended  to  supplant 
all  other  forms  of  printed  documentation. 

The  concurrent  and  semi-automated  generation  and 
modification  of  instructional  programs  with  the  design  and 
development  of  the  object  system  is  a  significant  new  approach. 
It  has  the  potential  to  make  a  major  contribution  toward  reducing 
communications  failures  and  making  more  efficient  use  of  people 
on  large  projects. 

4.  Steps  Toward  an  Operational  Prototype.  During  the  course  of 
this  project,  both  under  IBM  sponsorship  and  U.S.  Air  Force 
sponsorship,  a  considerable  amount  of  experimental  programming 
was  done.  The  programs,  most  of  which  were  done  in  PL/I,  have 
never  been  assembled  into  a  single,  integrated  system.  To  do  so 
would  reguire  some  additional  programming  and  some  modification 
to  existing  programs.  However,  these  tasks  could  be  performed 


a  new  concent., 
of  the  need  to 
and  document 
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and  the  result  would  be  a  prototype  system  performing  most  of  the 
functions  delineated  above  although  restricted  in  number  of 
terminals,  size  of  data  base,  and  sophistication  of  the 
interrogation  programs. 

a.  Programs  Completed 

The  individual  programs  available  now  are: 


on 

bre 

seq 

cat 

dat 

use 

now 

t.as 


(1)  Program  Analysis  (PA)  . 
PL/I ,  OS  Linkage  Editor,  and  OS/360  JCL 
aks  PL/T  code  down  to  the  level  of  a  se 
uence  of  statements)  and  recognizes  data 
egories:  SET,  USED,  and  CONTROL.  Whi 

a  occurrence  categories  would  be  desir 
ful  as  it  stands.  The  data  structure 
compatible  with  the  other  programs  but 
k  to  make  it  so. 


This  proqram  oper 
programs  only, 
qment  (a  straiqht- 
occurrences  in  t 
le  an  extension  of 
able  the  program 
compiled  by  PA  is 
it  would  bo  a  m 


ates 
Tt 
line 
h  r^e 
the 
is 
not 
ino  r 


(2)  Design  Interrogation.  A  program  exists  to 
interrogate  on  program  design  and  another  on  data  set  (file) 
design.  These  two  need  only  minor  revision  to  be  useful  as 
production  programs.  However,  they  were  designed  separately  and 
do  not  interface,  as  they  eventually  should.  That  is,  portions 
of  the  data  programs  should  be  callable  from  the  proaram 
documentation.  Both  programs  make  use  of  the  information 
retrieval  system  described  next. 

(3)  Information  Retrieval.  Actually  a  package  of 
subroutines  these  programs  can: 

o  Store  and  retrieve  data  items 

addressed  by  a  hierarchical  num¬ 
ber 


Extract 

key  word 

s 

f  r 

om  a 

text 

response 

and  corap 

ilf 

a 

a  key- 

word 

index  of 

a  d  oc  u  m  e 

nt. 

Search  the  key-wo 

rd 

in 

dex,  u 

sing 

Boolean 

logic,  t 

o  ret 

r  ieve 

ref- 

erences. 

These  programs  represent  an  extension  and  generalization  of  the 
retrieval  package  associated  with  the  original  program  analysis 
proqram. 

(4)  Report  Generation.  A  "standard''  report  mav 
be  defined,  by  providing  a  sequence  of  hierarchical  information 
element  numbers,  and  a  copy  of  this  report  may  be  generated  at: 
any  time  by  responding  "//REPORT"  to  any  interrogation  question. 
If  a  differently-constructed  report  is  desired,  the  requestor  may 
specify  which  information  elements  he  wants,  and  in  what 
sequence. 
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(5)  Instruction  Generation.  An  instruction 
generation  program  is  in  a  sufficiently  advanced  state  of 
debugging  to  be  included  in  the  basic  package.  When  completed, 
it  could  be  used,  as  well,  for  generation  of  any  additional 
interrogation  programs  needed  in  a  prototype  system. 

b.  Additional  Requirements 

These  five  programs  or  groups  of  programs  would  have  to 
be  integrated  and  some  operating  rules  {such  as  frequency  of 
updating)  devised.  In  addition,  two  additional  tasks  would  have 
to  be  undertaken  and  a  third  is  optional. 

(1)  Program  Interfaces.  In  the  larger  ESDP,  we 
have  assumed  that  all  documentation  is  available,  or  can  readily 
be  made  available,  on-line.  This  would  be  more  difficult  with  a 
prototype  which  would  be  presumed  to  be  sharing  a  computer  with 
other  programs.  A  minimum  amount  of  information  about  each 
proqram  in  the  system  should  be  made  available  in  a  partitioned 
data  base.  This  minimum  documentation  would  contain  primarily 
interface  information  so  that  if  program  A  calls  9,  sufficient 
information  is  available  on-line  to  provide  the  documentor  o*  A 
the  information  he  needs  about  B.  Conversely,  the  interface  data 
could  be  used  to  verify  that  the  call  to  B  was  executed 
correctly. 

To  accomplish  this,  the  ESDP  data  base,  upon  which  the 
other  programs  are  predicated,  must  be  revised,  and  the 
interrogation  and  program  analysis  programs  also  adjusted. 


pro 

con 

Mor 
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(2)  Multi-terminal  Operations.  Some  additional 
gramming  is  required  to  accommodate  many  terminals 

currently  where  all  are  not  involved  in  the  same  activity, 
e  than  one  terminal  communicating  with  one  program,  even 
ugh  executing  different  program  steps,  is  not  a  significant 
blem.  The  use  of  PL/I  which  produces  reentrant  code  plus  the 
ued  Telecommunications  Access  Method  (QTAM)  [ 5  ]  of  OS/160 
ch  buffers  incoming  and  outgoing  messages  makes  this  possible. 

problem  arises  when  the  terminals  must  communicate  with 
ferent  programs  that  cannot  both  reside  in  high-speed  memory 
once.  This  necessitates  roll-out/roll-in  for  storage 

ocation,  a  feature  that  is  not  now  available  but  will  be 

ndard  in  future  releases  of  OS/360.  Time  slicing  does  not 
ear  to  be  a  signifcant.  problem  at  this  time  since  ESDP 

ivities  are  not  likely  to  seize  the  CPU  for  long  periods  of 
e  without  being  interrupted  for  input  or  output  operations. 


(3)  Object  Programming  Language.  In  concent, 
ESDP  is  applicable  to  programs  written  in  any  language  although 
some  of  the  techniques,  particularly  program  analysis,  are 
specially  tailored  to  one  language.  So  far,  the  language  has 
always  been  PL/I.  To  use  ESDP  with  other  languages,  a  new 
program  analyzer  would  be  needed  and  possibly  some  revision  to 
the  interrogation  programs. 
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(4)  Computer  Requirements.  The  specific 
configuration  of  hardware  on  which  ESDP  is  to  be  run  depends  upon 
such  factors  as  the  size  of  the  object  system,  the  documentation 
requirements,  the  philosophy  of  the  system  management,  etc.,  and, 
therefore,  was  not  considered  a  valid  product  of  this  study. 
However,  since  we  have  defined  ESDP  as  a  support  system  for  large 
(25  or  more  programmers)  programming  projects,  we  can  make  some 
rough  estimates  of  hardware  requirements  based  solely  on  our 
experience  and  knowledge  of  systems  of  that  size. 

We  feel  that  a  medium  to  large  sized  CPU  (e.g.  ,  /360 
Mod  40-50)  should  he  made  available  for  ESDP.  It.  is  not 
necessarily  true  that  only  ESDP  can  be  run  on  this  CPU,  but  wo 
feel  that  the  same  computer  system  should  not  be  shared  between 
the  object,  system  and  ESDP. 

The  system  should  he  capable  of  supporting  a  minimum  ot 
ten  remote  terminals,  core  requirements  being  closely  related  to 
the  number  of  terminals  active  concurrently. 

Bulk  storage  for  ESDP  files  may  be  the  most  critical 
ESDP  hardware  requirement.  Some  minimum  amount  of  file  data  must 
be  on-line  at  all  times  with  a  larger  amount  off-line  on  disk 
packs,  tapes,  etc.  A  very  rough  guess  at  on-line  bulk  stonge 
requirements  is  30M  bytes  random  access  and  50M  bytes  serial 
access. 

Until  such  parameters  as  programming  language,  number 
of  terminals,  and  computer  configurations  can  be  established,  no 
precise  estimate  of  prototype  production  cost  can  be  given. 
However,  an  effort  of  the  same  order  of  magnitude  as  the  current 
contract  (3.5  man  years)  is  reasonable. 
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II 


ACQUISITION  OF  INFORMATION 


1.  Program  Ana  lysis.  Program  analysis  is  the  process  by  which 
ESDP  acquires  structured  information  on  a  completed  program.  By 
completed  here  we  mean  compilable,  for  the  program  analyzer  does 
not  have  the  elaborate  error-checking  mechanisms  of  a  compiler. 
The  object  program  used  need  not  be  complete  in  the  sense  of 
having  all  cole  written. 


There  are  four 
is  concerned  with 


The  first 

program.  In  Figure  1,  programs  B  and  C  are 
are  hierarchically  subordinate  to,  program  A. 
same  level,  neither  containing  the  other.  No 
is  illustrated  by  D  can  exist.  A  program  is 
or  wholly  independent  of  another. 


categories  of  structure  information, 
the  hiera rchic  organization  of  a 

contained  in,  hence 
B  and  C  are  at  the 
such  condition  as 
wholly  contained  in 


The  second  structural  feature  of  interest  is  the 
bra  nching,  or  control,  network.  This  is  described  by  listing  the 
possible  predecessors  and  successors  of  each  program  component. 
Predecessors  and  successors  are  defined  in  terms  of  execution. 
If  program  3  branches  to  C,  C  is  a  successor  of  B,  and  B  is  a 
predecessor  of  C. 


Category 
several  instances 
object  programs  is 
require  explicit 
information,  then, 
analysis . 


three  is  data  structure.  This  is  one  of 
where  use  of  a  high  order  language  for  the 
of  great  benefit  to  FSDP,  for  these  languages 
specification  of  data  sets.  Data  structure 
is  readily  available  to  ESDP  through  program 


Finally, 
there  is  a  network 
network  the  mode 
proqram  element, 
were  recognized 
program  planning 


by  analogy  with  the  prog r a m  control  structure 
of  data  occurrences.  We  record  in  this 
of  each  occurrence  of  a  data  item  name  in  a 
In  early  work  only  three  types  of  occurrence 
but  for  more  advanced  work,  particularly  in 
a  far  more  intricate  analysis  is  necessary. 


In  the  remainder  of  this  section, 
categories  are  discussed  in  greater  detail. 


the  four  structural 
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Figure  1 


A 


C 


A  Program 


c 


Organization 
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a 


Program  Hierarchy 


A  program  segment  is  defined  as  a  sequence  of 
line  code,  a  set  of  statements  or  commands  for  which 
only  possible  at  the  first  statement  and  branching 
possible  from  the  last  statement.  This  is  the  smalles 
programming  considered  in  work  to  date  but  we  could  go 
individual  statement  without  changing  the  substance 
description.  A  unit  of  programming  is  a  program  segment 
set  of  program  segments.  Thus,  a  unit  of  programming 
be  as  small  as  a  single  IF  statement  or  as  large  as 
System/360.  In  general,  we  are  concerned  with  acqu 
publishing  the  same  kind  of  documentation  about  a  UOP 
level  but  ,  in  practice,  we  would  vary  the  information 
nature  of  the  UOP. 


The  program  hierarchy  is  represented  by  a 
subordination  relationships  in  the  documentation  record 
UOP.  For  each  UOP  there  will  be  a  list  of  subordi 
superordinate  UOP's  (downward  and  upward  pointers). 

b.  Program  Control  Network 
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A  successor  of  a  UOP  is  any  UOP,  at  any  level,  that  may 
be  executed  immediately  after  the  first  one.  The  number  of 
possible  successors  may  be  quite  large,  as  might  happen  if  a  UOP 
in  PL/I  ends  with  GO  TO  LABEL(I)  when  LABEL  is  the  name  of  a 
label  array.  The  number  of  possible  successors  is  the  number  of 
elements  of  array  LABEL.  On  the  other  hand,  GO  TO  START  has  only 
one  successor. 
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The  program  control  structure  is  stored,  as  is  the 
hierarchy,  by  including  two  lists  in  each  UOP  documentation 
record.  One  list  contains  successors  and  one  predecessors. 


c.  Data  Structure 
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"lode  or  type  (fixed  decimal,  character 
floating  binary,  etc.) 

Length 

Initial  value 

A  data  set,  or  file,  is  not  fully  described  by  its 
hierarchical  structure.  The  nature  of  the  relationships  between 
elements,  say  two  variables  in  a  structure,  must,  be  made  known, 
but  this  cannot  be  determined  through  program  analysis. 

d.  Data  Occurrence  Network 


This  information  structure  tells 
where  it  is  changed,  where  it  affects  a  branching 
any  HOP  its  data  occurrence  table  represents 
description  of  that  UOP — a  statement  of  the  inp 
and  the  variables  governing  choice  of  the  no 
UOP.  Table  I  shows  a  far  more  detailed  system 
data  occurrences  than  has  been  used  in  exper 
should  he  understood  that  a  given  data  element  c 
than  one  category  within  any  UOP. 
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The  complete  program  structure  is  descrihable  in  terms 
record  outlined  in  Table  II. 
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Table  I.  Classification  of  Data  Usage  by  a  Program 
1.  Context  of  Appearance 

1.1  Assignment  Statement 

1.1.1  Computed  Value 

1.1.2  Argument 

1.2  Control  Statement 

1.2.1  Variable  I/O  Command 

1.2.2  Branching  or  Transfer  Command 

1.2. 2.1  Argument  or  condition  statement  (IF, 

ON  ...) 

1.2. 2. 2  Iterative  Control  Variable  (DO) 

1.2.2.  2.1  Initial  index  value 

1.2.  2.  2.2  Increment 

1.2. 2. 2. 3  Maximum  value  or  limit 

1.2. 2. 3  Variable  address 

1.3  Subroutine/Function/Macro  Calling  Seguence 

1.3.1  Transmitted  to  SR/Function/Macro 

1.3.2  Received  from  SR/Function/Macro 

1.4  Data  Declaration  Statement  (or  other  non-executable 
sta  tement) 

1.5  Input/Output 

1.5.1  Input 

1.5. 1.1  Input  Control  Variable 

1.5. 1.2  Data  Element  read  in 

1.5.2  Output 

1.5. 2.1  Output  Control  Variable 

1.5. 2. 2  Data  Element  written  out  or  transmitted 


2. 


3. 


Change  Status 


2. 1 


Value  Changed  by  Containing  Statement 

2.1.1  Value  Directly  Assigned  by  Assignment  Statement 

2.1.2  Value  Directly  Changed  by  DO  Statement 

2.1.3  Value  Directly  Changed  by  Variable  I/O  Statement 


2.2  Value  not  Changed  by  Containing  Statement 


Structural  Role 


3.1  Data  Element  is  a  Structure  or  Array 


3.2  Index  or  Subscript 

3.2.1  Value  of  an  Index 

3.2.2  Element  of  an  Index  Term 


3. 3  Scalar  Item 
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Table  II.  Program  Report  Outline 

1.  Identification 

1.1  Author 

1.2  Name  of  Program  or  System 

1.3  Document  Modification  Data 

1.3.1  Modification  Number 

1.3.2  Author  of  Modification 

1.3.3  Date  of  Modification 

1.3.4  Date  of  Initial  Entry 

1.4  Level  of  Documentation 

1.4.1  Designation 

1.4.2  Program  Type 

2.  Introduction 

2.1  Program  Summary 

2.1.1  DescriDtion  of  Logic 

2.1.2  Program  Apolication 

2.1.3  Program  Organization 

2.2  Entry 

2.3  Exit 

2.4  Data 

2.4.1  General  Summary 

2.4.2  Inputs 

2.4. 2.1  Summary  of  Inputs 
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Table  II.  Program  Report  Outline  (Continued) 


2.4. 

2. 2  Input  Files 

2.4. 

,2.2.n.2  Definition 

2.  4. 

3  Outputs 

2.4. 

,3.1  Summary  of  Outputs 

2.4. 

,  3. 2  Output  Files 

2.4. 

.3. 2.n  Output  File  Number 

2.4. 

.  3. 2. n. 1  Name 

2.4. 

.  3.  2.n.2  Definition 

2.4. 

,4  Internal  Data 

2.4. 

.4.1  Summary  of  Internal  Data 

2.  4. 

.4.2  Internal  Files  and  Data  Sets 

2.4. 

,4.2.n  Internal  File  Number 

2.4. 

,4.2.n.l  Name 

2.4. 

,4.2.n.2  Definition 

3. 

Program  or  System  Functions 

3.1 

Description  of  Logic 

3.2 

External  References 

3.2. 

.n  Reference  Number 

( 
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Table  II.  Program  Report  Outline  (Continued) 


4.  Program  or  System  Composition 

4.1  General  Description  of  Structure 

4.2  Subordinate  UOP 

4.2. n  Subordinate  Number 

4.2. n.l  Name 

4.2. n.2  Function 

4.2. n.3  Inputs  to  Subordinate 

4.2. n.3.n  Input  Number 

4.2. n.4  Outputs  from  Subordinate 

4.2. n.4.n  Output  Number 

4.2. n.5  Internal  File  of  Subordinate 

4.2. n.5.n  Internal  File  Number 

4.2. n.6  Entry-Exit  Conditions 

4. 2.  n. 6.1  Summary  of  Entry  Conditions 

4.2. n.6.2  Summary  of  Exit  Conditions 

4.2. n.6.3  Type  of  Decision  Governing  Exit 

4.2. n.6.3.1  Successor  (if  unconditional) 

4.2. n.6.4  Exit  Control  Variables  (if  conditional) 

4.2. n.6.4.n  Control  Variable  Number 

4.2. n.6.5  Successors  to  Subordinate  (if  conditional) 

4.2. n.6.5.n  Successor  Number 

4.2. n.6.S.n.l  Name 

4.2. n.6.S.n.2  Control  Conditions  Causing  Path 

4. 2 .  n. 6. 5. n . 3  Purpose  of  Taking  Path 


17 


Table  II.  Program  Report  Outline  (Continued) 


5.  Control 

5.1  Entry 

5.1.1  General  Description  of  Entry 

5.1.2  Entry  Points  (if  program  level) 

5.1.2. n  Entry  Point  Number 

5.1.2. n.l  Identification 

5.1.2.  n. 2  Conditions  for  Using  Entry 

5.1. 2.  n.  3  Subordinate  Containing  Entry 

5.1. 2.  n. 4  Predecessors 

5.1.2. n.4.n  Predecessor  Number 

5.2  Exit 

5.2.1  Exit  Conditions 

5.2. 1.1  General  Description  of  Exit  Condition: 

5.2.1. 2  Type  of  Decision  Governing  Exit 

5.2. 1.2.1  Successor  Program  or  System  (if 

5. 2. 1.3  Description  of  Decision  Functions 

5. 2. 1.4  Variables  Controlling  Decision  (if 

5. 2.1. 4.  n  Variable  Number 

5.2.1. 4.  n. 1  Name 

5.2.1.4. n.2  Definition 

5.2.2  Successors  (if  conditional) 

5. 2 . 2.  n.  1  Name 

5. 2.2.  n. 2  Control  Conditions  Causing  Path 

5.2.2. n.3  Purpose  of  Taking  Path 


cond i t iona 1) 


conditional) 
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Table  IT.  Program  Report  Outline  (Concluded) 


6.  Data 

6.1  General  Summary 

6.2  Inputs 

6.2.1  Summary  of  Inputs 

6.2.2  Input  File 

6.2.2. n  Input  File  Number 

6. 2. 2.  n. 1  Name 

6. 2.2.  n. 2  Source 

6.2.2. n.3  Description  of  Content 

6.2.2. n.U  Structure 

6.3  Outputs 

6.3.1  Summary  of  Outputs 

6.3.2  Output  Files 

6.3.2. n  Output  File  Number 

6.3.2. n.l  Name 

6.3.2. n.2  Destination 

6. 3.2.  n. 3  Description  of  Content 

6. 3.2.  n. 4  Structure 

6.4  Internal  Data 

6.4.1  Summary  of  Internal  Data 

6.4.2  Internal  Files  and  Data  Sets 

6.4.2. n  Internal  File  Number 


6.  4 . 2.  n.  1 
6. 4 . 2.  n .  2 


6. 4.2. n. 3 


Name 

Description  of  Content 
Structure 
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2.  Interrogation 


program 


Computer 
system  for 


Assisted  Interrogation  (CAINT) 
man-machine  communication. 


is 


a  computer 


Its  principal  function  is  to  enable  a 
computer  to  elicit  information  from  a  man  by 
interrogating  him — asking  him  a  program  of 
questions  where  the  program  follows  a  logical 
course  depending  both  on  information 
available  before  the  interrogation  started 
and  on  that  gained  during  the  interrogation. 
The  information  acquired  is  intended  to  be 
put  to  immediate  use,  in  updating  a  data 
base,  generating  reports,  or  driving  other 
interrogations. 


During  the  course  of  an  i 
interrogee  will  be  qiven  i 
as  asked  questions,  and  he 
questions  as  well  as  provi 
a  CAINT  interrogatio 

conversational,  with 
questions  flowing  in  both 
conversation,  particularly 
man  direction,  is  somewhat 
machine’s  versatility  bei 
repertoire  of  general 
statements  which  are  pa 
assembled  for  use  a 
conversational  range  of  the 
depends  upon  a  system  use 
designing  these  stat.eme 
somewhat  akin  to  computer  p 


nterrogation,  the 
nformation  as  well 
may  ask  his  own 
de  answers.  Thus, 
n  is  truly 

information  and 
directions.  The 
in  the  machine-to- 
stereotyped,  the 
ng  limited  by  a 
ized,  fragmented 
rticularized  and 
s  needed.  The 
computer,  then, 
r’s  versatility  in 
nts  —  a  process 
rogr  amming.  [  1 "] 


In  planning  an  interrogation  program  the  designer  must 
constantly  keep  three  objectives  in  mind:  (1)  that  of  acquiring 
the  set  of  information  that  best  accomplishes  the  documentation 
of  a  program,  (2)  that  of  assuring  that  the  interrogation  program 
is  thoroughly  debugged,  and  (3)  that  the  programmer  or  other  user 
who  is  responding  to  an  interrogation  understands  the  manner  in 
which  elicited  information  is  to  be  used.  It  should  be  clear 
that  the  successful  application  of  ESDP  to  any  project  depends 
heavily  upon  the  degree  to  which  these  objectives  are  met. 
However,  they  are  essentially  the  same  requirements  imposed  on 
the  development  of  any  computer  program. 


The  need  for  skill  and  accuracy  on  the  part  of  an 
interrogation  programmer  is  no  different  from  the  same  need  in 
conventional  programming.  Interrogation  programming,  as  we  shall 
brinq  out,  can  be  mechanically  easier  than  conventional 
programming,  but  properly  identifying  objectives  and  ensuring 
proper  user  interface  may  be  more  difficult.  Because  this  is  the 
primary  channel  for  the  entry  of  much  information  into  ESDP,  it 
is  highly  important  that  users  have  skill  in  responding  to 
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interrogations  and  in  interpreting  questions  in  terms  of  their 
own  programs. 


Guiled  by  the  structure  of  the  object 
program,  and  design  information  previously 
contributed  by  the  programmer  and  others, 
CAINT  interrogates  a  programmer  about  his  own 
program  and  elicits  a  detailed,  up-to-date, 
program  description.  It  can  also  be  used  for 
other  highly  structured  reporting  activities 
and  for  advanced  educational  programs.  [1] 


CAINT,  which  was  developed  as  a  subsystem  of  E5DP 
enables  programmers  to  document  programs  while  still  at  the 
design  level  and  to  add  elaboration  and  explanation  to 
documentation  acquired  by  program  analysis.  As  we  have  pointed 
out  earlier,  the  process  of  interrogation  is  not  logically 
different  for  those  two  modes  of  operation.  All  that  changes  is 
the  wording  of  questions,  and  possiblv  the  choice  of  which 
questions  to  ask. 


An 

object  of  i 
structure.  T 
are  prepared 
questions  or 
question,  an 
response  in  t 
and  in  anal 
programmable 
structure  av 
interroqat ion 
Language. 


interrogation  is  ba 
nterrogation  is  t 
o  this  end  a  set  of 
and  a  program  i 
combination  of  fra 
alyzes  the  respon 
he  data  structure, 
yzing  a  response, 
function  of  the  dat 
ailable  to  the  prog 
program  and  it  is 


sed  upon  a  data  structure.  The 
o  create,  complete  or  modify  this 
questions  and  question  fragments 
s  written  which  decides  which 
gments  to  use,  asks  the  assembled 
se  and,  if  valid,  stores  the 
In  deciding  what  question  to  use 
the  program  may  make  use  of  any 
a  structure  or  of  any  other  data 
ram.  Such  a  program  is  called  an 
written  in  the  CAINT  Executive 


More  details  of 
below.  At  this  point  we 
principles : 


interrogation  will 
wish  to  emohasize 


be  brought  out. 
the  following 


a.  To  carry  out  an  interrogation,  an  interrogation 
proqram  must.  be  written.  This  program  uses  any  function  of  the 
data  base  to  make  decisions,  and  results  in  acquiring  new 
information  for  storage  in  the  data  base. 


b.  Interrogation  programs  are  intended  to  be  readily 
modified.  A  basic  assumption  is  that  each  using  organization 
will  have  different  needs  or  preferences  from  each  other 
organization,  and  CAINT  is  desiqned  to  accommodate  these 
differences. 


c.  Interrogation  was  originally  conceived  to  operate 
upon  the  results  of  program  interrogation — to  ask  the  programmer 
for  explanation  of  the  structure  of  his  program.  Further 
investigation  suggested  the  value  of  interrogation  as  a  design 
tool,  for  interrogating  programmers  about  oroqrams  before  their 
completion,  and  as  an  instructional  tool  for  presenting  existing 
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information  to  the  programmers. 


3. 

whe 

The 

pro 

fir 

fil 

cur 

to 


Design  Interrogation  Program  documentation  is  most  valuable 
n  it  is  available  to  assist  decision-makers  and  designers. 

point  of  greatest  need  for  this  assistance  comes  early  in  a 
ject,  when  there  are  no  completed  programs.  It  is  during  the 
st  few  months  when  program  interfaces  are  being  specified, 
es  being  designed,  and  schedules  being  laid  out  that  valid 
rent  documentation  would  be  of  most  value  and  is  least  likely 
be  available. 


Even  at  the  earlies 
designers  will  have  ideas  in 
structure,  program  interface  a 
these  initial  ideas  will  change 
for  recording  them  and  dissemina 


Design  interrogation 
analysis  and  interrogation — the 
program  and  data  structure 
primitive  a  program  model  as 
with  a  list  of  files  used 
communicated  with,  can  be  very 
document  is  created  for  each 
we  can  add  information  on 
milestones,  and  then  the  sk 
form. 
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The  original  concept  of  ESDP  assumed  the  full  use  of 
design  interrogation,  even  in  the  absence  of  a  program 
specification.  The  intent  was  that  a  specification  would  evolve 
through  repetitive  interrogation,  and  that  when  the  program  was 
eventually  written,  it  would  match  well  with  the  design  data  in 
structure.  The  successful  use  of  this  concept  relies  heavily 
upon  the  cooperation  and  probably  enthusiasm  of  its  users,  for 
they  must  reply  to  necessarily  vague  guestions,  in  order  to 
introduce  the  program  structure  to  the  system,  and  must 
anticipate  the  use  to  be  made  of  their  responses  in  order  to 
improve  future  interrogations.  It  is  possible  that  design 
interrogation  will  be  more  effective,  at  least  during  the 
exploratory  phases  of  developing  ESDP,  when  applied  to  data 
rather  than  to  programs.  Data  files  are  definitely  of  interest 
to  more  than  the  originating  programmer,  their  design  tends  to 
change  often,  and  changes  can  have  major  impact  on  other  users. 
Hence,  all  the  communication  problems  of  the  system  as  a  whole 
exist  for  data  as  a  subsystem,  but  the  manner  of  describing  data 
structures  is  perhaps  more  consistent  than  for  programs,  and  the 
information  needed  about  a  file  under  design  is  more  precise  and 
generally  better  agreed  upon  than  for  programs.  Hence,  an  option 
open  to  systems  managers  is  to  use  design  interrogation  for  both 
programs  and  data,  for  data  only,  or  neither. 

Design  interrogations  if  used  must  be  repeated  at 
f re guen t.  intervals.  Once  the  basic  framework  of  the  system  is 
laid  out  conflicts  and  omissions  become  evident  which  lead  to  an 
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almost  endless  series  of  changes.  Gradually,  however,  the 
structure  should  begin  to  stabilize  and  the  resultant 
documentation  should,  ideally,  be  identical  to  that  to  be 
acquired  through  program  analysis.  That  there  will  be 
differences  between  plan  and  execution  is  certain  and  for  this  a 
reconciliation  process  (Section  II. 6)  has  been  devised. 

Automatic  dissemination  of  design  documentation  can  be 
a  powerful  management  aid.  All  programmers,  designers  and 
managers  can  see,  readily,  the  current  status  of  the  entire 
system.  Even  more  significantly,  they  can  immediately  be 
apprised  of  any  design  changes  related  to  their  own  areas  of 
work. 
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THIS  IS  A  PROGRAM  DESIGN  INTERROGATION  1/1/68 

WHAT  IS  YOUR  NAME? 

JOHN  DOE 

WHAT  IS  THE  NAME  OF  THE  OOP  YOU  WISH  TO  DISCUSS? 

ALTAIRFLD 

DESCRIBE  THE  PURPOSE  OF  THIS  UOP 

THIS  IS  AN  ILLUSTRATIVE  PROGRAM  CONCEPT  TO  DEMONSTRATE  ESDP 
TECHNIQUES.  IT  IS  BASED  ON  A  FUNCTION  THAT  MIGHT  BE  P  ER  FOR  MFD 
BY  AN  ACTUAL  AIR  TRAFFIC  CONTROL  SYSTEM.  IT  USES  PARAMETERS 
FOR  AN  INDIVIDUAL  AIRCRAFT,  TOGETHER  WITH  A  STORED  FILE  OF 
AIRCRAFT  CHARACTERISTICS,  TO  COMPUTE  THE  DISTANCE  THE  PLANE 
CAN  FLY  WITH  ITS  REMAINING  FUEL.  THEN  IT  SELECTS  THE  FIRST 
ALTERNATE  AIRFIELD  THAT  CAN  BE  REACHED. 

SELECT  THE  NUMBER  THAT  BEST  DESCRIBES  THE  LEVEL  OF  ALTAIRFLD: 

1.  SYSTEM,  2.  JOB,  3.  LOAD  MODULE,  4.  OPJECT  MODULE, 

5.  CALL  MODULE,  6.  GROUP,  7.  SEGMENT 
S 

SELECT  THE  LETTER  OF  THE  TOPIC  YOU  WOULD  LIKE  TO  DISCUSS 

A.  PURPOSE  OF  ALTAIRFLD,  B.  PROGRAM  STRUCTURE,  C.  PROGRAM 

CONTROL,  D.  DATA,  E.  ERRORS,  F.  TESTING 
B 

DO  YOU  KNOW  THE  NAME  OF  A  SUPERORDINATE  UOP  CONTAINING  ALT ATRFLD 

IF  SO,  GIVE  THE  NAME,  OTHERWISE  ANSWER  NO 
TRAFFIC 


Figure  2.  SAMPLE  INTERROGATION 


24 


WOULD  YOU  LT  KB  TO  A.  CONTINUE  WITH  ALTAIRFLD  OR  B.  DISCUSS  TRAFFIC 
_  % 


ARE  THERE  ANY  SUBORDINATE  UOP  CONTAINED  IN  ALTAIRFLD? 

YES 

LTST  ALL  THE  UOP  THAT  ARE  IMMEDIATELY  CONTAINED  IN  ALTAIRFLD  +LIST+ 
INITIAL 
DISTCALC 
SELECT 
OUTPUT 
//END 

WOULD  YOU  LIKE  TO  TALK  ABOUT: 

1.  INITIAL 

2.  DISTCALC 

3.  SELECT 

4.  OUTPUT 

5.  OR  CONTINUE  WITH  ALTAIRFLD 
5 

NOW  SUMMARIZE  THE  STATIC  ORGANIZATION  OF  ALTAIRFLD,  SHOWING  THE 
RELATIONSHIP  OF  IT  TO  TRAFFIC  PLUS  THE  RELATIONSHIP  OF: 

INITIAL 

DISTCALC 

SELECT 

OUTPUT 

TO  ALTAIRFLD 

ALTAIRFLD  IS  INVOKED  BY  A  CALL  STATEMENT  IN  TRAFFIC.  WITHIN 
ALTAIRFLD,  INITIAL,  DISTCALC,  SELECT,  AND  OUTPUT  ARE  INVOKED 
SEQUENTIALLY  IN  THAT  ORDER. 


Figure  2.  SAMPLE  INTERROGATION  (Concluded) 
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TITLE  PAGE  INFORMATION 


1  HOP  NAME 

ALTAIRFLD 

2.1  LEVEL 

ALTAIRFLD  IS  A  CALL  MODULE  UOP. 

2.2  AUTHOR 

JOHN  DOE 

2.1  DATE 

680118 

EXPLANATION  OF  FUNCTION 
3  PURPOSE 

THIS  IS  AN  ILLUSTRATIVE  PROGRAM  CONCEPT  TO  DEMON¬ 
STRATE  ESDP  TECHNIQUES.  IT  IS  BASED  ON  A 
FUNCTION  THAT  MIGHT  BE  PERFORMED  BY  AN  ACTUAL 
AIR  TRAFFIC  CONTROL  SYSTEM.  IT  USES  PARAMETERS 
FOR  AN  INDIVIDUAL  AIRCRAFT,  TOGETHER  WITH  A 
STORED  FILE  OF  AIRCRAFT  CHARACTERISTICS,  TO 
COMPUTE  THE  DISTANCE  THE  PLANE  CAN  FLY  WITH  ITS 
REMAINING  FUEL.  THEN  IT  SELECTS  THE  FIRST 
ALTERNATE  AIRFIELD  THAT  CAN  BE  REACHED. 

BASIC  FORM  OF  THIS  UOP 

4.1  SUMMARY 

ALTAIRFLD  IS  INVOKED  BY  A  CALL  STATEMENT  IN 
TRAFFIC,  WITHIN  ALTAIRFLD,  INITIAL,  DISTCALC, 
SELECT,  AND  OUTPUT  ARE  INVOKED  SEQUENTIALLY 
IN  THAT  ORDER. 

4.2  SUPERORDINATE  UOP 


TRAFFIC 

4.4  SUBORDINATE  HOPS  SUB-NAME 

INITIAL  1 

DISTCALC  2 

SELECT  3 

OUTPUT  4 


Figure  3.  ESDP-CAINT  PROGRAM  DOCUMENTATION  FOR  ALTAIRFLD 
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LIST  OF  MODIFICATIONS  TO  THIS  UOP 
2.5  MODIFICATIONS 

ALTAI RFLD — REPORT  COMPLETED 


ACTUAL 

IEN 

3.00 

AIR 

IEN 

3.00 

AIRCRA 

IEN 

3.00 

AIRFIE 

IEN 

3.00 

ALTAIR 

IEN 

4.01 

ALTERN 

IEN 

3.0  0 

BASED 

IEN 

3.00 

CHAR  AC 

IEN 

3.0  0 

COMPUT 

IEN 

3.00 

CONCEP 

IEN 

3.00 

DISTAN 

IEN 

3.00 

DISTCA 

IEN 

4.04 

TEN 

4.01 

ESDP 

IEN 

3.00 

FILE 

IEN 

3.00 

FLY 

IEN 

3.00 

FUEL 

IEN 

3.00 

FUNCTT 

IEN 

3.00 

ILLUST 

IEN 

3.00 

INDIVI 

IEN 

3.00 

INITTA 

IEN 

4.04 

TEN 

4.01 

INVOKE 

IEN 

4.01 

ORDER 

IEN 

4.01 

OUTPUT 

IEN 

4.04 

IEN 

4.  01 

PARAME 

IEN 

3.00 

PERFOR 

IEN 

3.00 

PLANE 

IEN 

3.0  0 

PROGRA 

IEN 

3.00 

REACHE 

IEN 

3.00 

REMAIN 

IEN 

3.00 

SELECT 

IEN 

3.00 

IEN 

4.04 

SEQUEN 

IEN 

4.01 

STORED 

IEN 

3.00 

SYSTEM 

IEN 

3.00 

TECHNI 

IEN 

3.00 

TOGETH 

IEN 

3.00 

TRAFFI 

IEN 

3.00 

IEN 

4.01 

Figure  3.  ESDP-CAINT  PROGRAM  DOCUMENTATION  FOR  ALT  AIR FLD 


(Concluded) 
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4.  Changes  in  Documentation.  Changing  existing  documen 
will  he  the  normal  mode  of  operation  of  ESDP  once  an  i 
program  description  has  been  entered.  A  programmer  will  n 
asked  to  repeat  previously  entered  information  if  he  -just 
to  enter  a  change.  Changing  operates  on  the  principle  tha 
programmer  describes  the  information  element  or  program  e 
that  is  to  be  changed  and  analysis  or  interrogation  wi 
performed  only  on  the  stated  items. 


In  interrogation  the  programmer  ident 
information  element  by  number — this  being  a  hiera 
applied  to  each  separable  item  of  information  in  the  f 
author  of  the  interrogation  program  will  have  compiled 
questions  pertaining  to  that  element.  Only  these  ques 
be  asked  again  and  within  these  prescribed  lim 
reinterrogation  may  follow  a  different  sequence  of  ques 
the  original.  The  programmer  is  not  restricted  to  maki 
at  the  bottom  of  the  hierarchy.  He  may  specify  a 
element  which  contains  many  subordinates,  and  if  he  doe 
be  reinterrogated  about  ali  of  them. 
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Program  analysis  will  also  o 
basis.  In  this  case,  the  programmer  iden 
UOP  not  affected  by  the  change  and  it, 
no  other  program  components,  will  be  rean 
is  created.  The  structure  of  the  program 
ESDP  is  unable  to  match  old  UOP's  with 
newly  computed  data  as  changes  to  a 
Instead,  a  parallel  structure  must  be  cr 
later  by  a  man-machine  process. 
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5.  incremental  Documentation.  The  term  i ncrementa 1 
documentation  refers  to  ESDP’s  ability  to  accept  changes  to 
existina  documentation  without  completely  regenerating  it.  It  is 
a  feature  of  ESDP  that  facilitates  production  of  current, 
documentation  of  an  object  program  system  as  it  evolves, 
reflecting  the  current  status  of  programmina  through  the  stages 
of  design,  debugging,  and  modification,  with  a  minimum  of  effort 
by  the  user. 


a.  Design  Phase 


The  inf 

the  desiqn  phase 
interrogation, 
program  analysis, 
wholly  concerned 


ormat ion  in  the  ESDP  documentati 
of  the  object  system  is  entirely 
Since  the  files  contain  no  data 
the  incremental  documentation  f 
with  incremental  interrogation. 
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The  purpose  of  incremental  interrogati 
documentors  to  make  changes  in  documentation  f 
with  a  minimum  of  effort  and,  at  the  same  time 
when  a  change  is  made,  all  consequences  of  tha 
effected.  For  example,  if  we  were  to  change  the 
item  from,  say,  variable  to  array,  it  would  be 
some  other  implied  changes  as  well,  relating  to 
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would  not.  previously  have  been 


as  length  of  the  array  which 
present  in  the  file. 
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In  experimental  interrogation  we  have  used  a  subroutine 
linkage,  CALL  NEXT,  as  the  test  at  the  end  of  each  element.  The 
NEXT  subroutine  determines  if  the  responder  is  involved  in  an 
update  activity.  If  so,  the  element  has  been  used  as  a 
subroutine  and  control  is  passed  by  NEXT  back  to  the  point  from 
which  the  element  was  called.  Otherwise,  control  will  be  passed 
to  the  next  sequential  element  via  a  RETURN  statement. 


The  control  logic  for  incremental  interrogation 
essentially  revolves  around  a  table  of  information  element 
numbers  (IEN’s)  or  documentation  items,  and  the  interrogation 
elements  that  must  be  used  in  order  to  update  the  TEN.  The  user 
inputs  the  IEN,  the  system  looks  that  number  up  in  the  table, 
retrieves  the  list  of  interrogation  elements  that  must  be 
executed,  and  carries  out  the  interrogation.  The  newly  elicited 
information  is  later  merged  into  the  existing  documentation 
files. 


This  description  has  assumed  the  documentor  knows 
IEN’s  he  wants  to  modify.  Such  is  not  always  the  case, 
can  define  the  area  of  interest  only  in  terms  of  subject  m 
he  may  use  the  information  retrieval  system  to  find  those 
that  are  related  to  his  known  subject.  He  could,  then,  sta 
interrogation  with  a  request  to  update  all  documen 
pertaining  to  input  operations  from  tape  units,  retriev 
appropriate  IEN's,  and  then  proceed  normally. 

To  carry  out  a  document  modification,  the  syst» 
must,  identify  the  subject  concerned,  whether  a  Uni 
Programming,  Unit  of  Data,  Graphic,  etc.,  and  the  name  or 
of  that  entity.  He  must  then  identify  the  document  from  wh 
is  making  up  this  modification.  This  will  have  to  be 
identifiable  report,  flow  chart,  retrieval  output,  or 
message  on  a  CRT,  but  the  system  must  know  what  is 
modified.  Next  he  enters  the  change  command,  whethe 
delete ,  or  change,  and  then  enters  new  information  in  respo 
the  ensuing  interrogation  questions. 

There  is  some  value  in  holding  changes  in  a  se 
file,  at  least  temporarily,  until  a  change  session  is  com 
and  the  author  is  satisfied  he  has  made  all  the  c 
correctly.  For  system  reliability  purposes,  we  should  mi 
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the  possibility  of  a  system  failure  occurring  during  the  posting 
of  a  change  to  a  file.  For  this  reason,  it  is  better  to  make  the 
complete  change,  hold  it  in  working  storage,  then  apply  it  all  at 
once  to  the  main  file. 

There  are  two  tables  involved  in  the  determination  of 
what  interrogation  elements  to  use  for  an  incremental 
interrogation.  The  Sequence  Table  (illustrated  in  Figure  4) 
provides  a  list  of  interrogation  elements  for  each  information 
element  number  (IEN) .  This  list,  in  work  so  far,  has  been  in  the 
form  of  a  set  of  start  and  end  points  for  contiguous 
interrogation  elements,  i.e. ,  for  a  given  IEN,  we  are  directed  to 
start  at  interrogation  element  a  and  continue  sequential 
operation  of  the  interrogation  program  until  element  b  is 
reached,  at  which  time  return  is  made  to  the  sequencing  program. 
There  may  be  any  number  of  such  start-end  pairs.  There  may  be 
any  number  of  such  start-end  pairs. 

The  next  list  is  the  one  used  to  convert  from  report 
section  numbers,  for  any  ESDP  report,  to  information  element 
numbers,  for  use  in  the  Sequencing  Table.  This  requires  the 
maintenance  of  a  dynamic  file  that  records  what  information 
elements  were  used  and  under  what  report  section  number,  for  each 
report  produced.  Since  many  reports  will  be  working  papers  only, 
the  records  of  these  reports  will  have  to  be  purqed  periodically, 
and  when  this  happens  any  subsequent  changes  would  have  to  be 
made  by  using  a  different  report  as  the  basis  for  regenerating 
the  report. 

Report  section  of  information  element  numbers  may  have 
indexable  components.  For  example,  if  Section  1.2  is  concerned 
with  system  inputs,  the  first  system  input  might  be  described  in 
Section  1.2.1,  the  second  in  1.2.2,  etc.  Then,  if  the  description 
of  an  input  starts  with  its  name,  the  name  of  the  first  input 
might  be  filed  in  element  1.2.1. 1,  the  name  of  the  second  in 
1. 2.2.1,  etc.  The  third  component  of  these  index  numbers  is  the 
index  of  the  inputs,  and  we  call  this  component  of  the  IEN 
indexable. 


In  the  sequence  table,  it  is  neither  necessary  nor,  for 
space  reasons,  desirable  to  have  an  entry  for  each  possible  value 
of  an  indexable  IEN.  Accordingly,  we  have  used  the  technique  of 
replacing  an  indexable  number  in  this  table  with  the  letter  n. 
Thus,  the  IEN  for  system  inputs  might  be  represented  in  this 
table  as  1.2.n,  and  for  all  input  names  as  1.2.n.  1.  In  matching 
an  IEN  entered  by  a  documentor,  the  system  treats  the  n  as  a 
universal  match  character,  and  accents  any  numeric  value  for  this 
component  within  a  legal  range  for  this  number.  For  example,  if 
he  declares  his  intent  to  change  the  description  of  a  data 
element  identified  by  IEN  1.2.3,  the  system  would  respond,  "This 
is  item  SALARY.  Is  this  the  one  you  want  to  change?" 
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IEN 

Start 

End 

Start 

End 

1.1 

Label  1 

Label 

2 

Label  3 

Label  4  ... 

1.1.1 

Label  S 

Label 

6 

— 

1.  1.2 

1.2 


1.  2.  n 


1.  2.  n.  1 


l.  2. n. 2 


1.  2.  n.  2.  n 


Note  the  use  of  the  symbol  n  whenever  an  element 
can  repeat,  with  a  different  TEN  each  time.  Note 
also,  that  there  may  be  any  number  of  indexable 
components  of  any  TEN 

Figure  4.  Sequence  Table 
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b.  Debugging  and  Modification  Phases 

Once  code  has  been  written  for  the  object  system,  ESDP 
must  contend  with  both  the  data  derived  from  interrogation  and 
that  derived  from  program  analysis.  When  confronted  with  the 
need  to  modify  documentation  files  to  reflect  a  program  change, 
ESDP  will  have  in  its  files  the  following  hinds  of  data. 

(1)  Structure 

Program  structure  will  be  reflected  in  two  dimensions, 
hierarchy  and  process  flow.  Each  OOP  may  be  contained  in  higher 
order,  superordinate  UOP  and  may  also  contain  subordinate  UOP. 
The  process-flow  dimension  relates  UOP  by  possible  flows  of  the 
execution  of  the  program.  Each  UOP  may  receive  control  from 
predecessor  UOP  and  may  pass  control  to  other  successor  UOP. 

( 2)  Fo rm al  Text 

This  text  comprises  the  original  source  language  object 
system  program  statements. 

(3)  Data  References 

The  data  names  used  in  each  UOP  will  be  listed.  Tn 
addition  to  the  names  themselves,  there  will  be  indicators 
depicting  attributes  and  special  codes  categorizing  the  data 
usa  ge. 

( 4)  Narrative  Text 

The  narrative  text  that  has  entered  the  system  via 
interrogation  is  in  the  ESDP  files.  Each  element  of  text  is 
tagged  with  a  variety  of  identifiers  such  as  the  question  number 
that  elicited  the  text,  IEN  number,  keywords,  associated  UOP,  or 
data  names,  etc. 

(5)  Reports 

There  may  also  be  a  number  of  reports  on  file.  These 
will  essentially  be  rearrangements  of  the  narrative  text  into 
various  report  outlines.  In  the  reports,  each  element  will  be 
identified  by  the  report  number  plus  IEN. 

Adding  and  deleting  source  program  statements  can  be 
automatically  reflected  in  the  structure  files.  This  is  done 
through  manipulation  of  pointers.  At  the  same  time,  however,  it 
appears  that  at  some  point  of  modification  complexity  it  will  be 
more  economical  to  rerun  the  entire  program  analysis.  That  is, 
if  a  great  deal  of  the  program  structure  is  changed  it  may  be 
desirable  to  flush  all  data  with  a  program  analysis  source  code 
and  resubmit  the  program  for  program  analysis. 

If  we  process  changes  to  source  programs  to  update 
structure  files,  we  are  left  with  the  situation  where  the  program 
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analysis  data  has  been  updated  automatically  and  the  narrative 
text  has  not.  At  this  point  we  need  to  link  applicable  elements 
of  text  to  the  program  analysis  structure,  interrogate  on  new 
portions  of  structure,  reinterrogate  to  elicit  changed  narrative 
or  to  delete  narrative.  These  operations  will  be  discussed  below 
under  II. 6,  Reconciliation.  Our  solution  to  this  last  step  of 
linking  stored  textual  data  with  updated  portions  of  structure  is 
through  use  of  the  reconciliation  commands. 
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iliation.  Reconciliation  is  the  process  of  combining 
from  more  than  one  source  that  is  descriptive  of  the 
.  The  assumption  is  made  that  there  are  discrepancies 
formation  provided  by  the  different  sources.  If  there 
crepancies,  reconciliation  would  be  an  almost  trivial 
argely  one  of  m erg in g  records.  Discrepancies  will  be 
t.ances  unexpected  by  the  programmer.  He  will  expect  a 

written  his  program  to  be  in  some 
design  documentation.  Such  a 
his  failure  to  update  design 
difference  arises  when  the 
unknowingly  violates  his  design  specifications.  His 
re  is  recognizing  that  differences  exist  and 
those  elements  of  each  data  record  that  do  coincide. 
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Perhaps  we  should  also  point  out  what  reconciliat 
not  intended  to  achieve.  It  is  not  the  intent  of  ESDP  to  a 
automatically  to  correlate  finished  programs  with 
specifications  to  determine  if  specif icat ions  have  been 
Although  this  would  be  an  interesting  and  useful  featur 
type  of  correlation  is  a  highly  subjective  process 
mechanization  infeasible.  The  purpose  of  reconciliation  i 
is  to  avoid  complete  duplicate  entry  of  information  on  the 
of  the  user.  If  the  system  has  acquired  information  a 
program  via  design  interrogations,  it  is  reasonable  to 
that  at  least  a  large  part  of  this  information  will  st 
valid  once  the  proqram  is  written  and,  therefore,  should  he 
in  some  way  to  the  files  built  by  proqram  analysis 
information  acquired  during  design  interrogation  may  not  i 
all  of  the  details  known  by  the  programmer  at  the  time  of  p 
analysis.  Therefore,  an  interrogation  following  program  an 
will  be  conducted  to  provide  more  details  and  to  supply  c 
to  the  design  information. 
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Reconciliation  problems  exist  in  regard  to  data 
documentation  as  well  as  program  logic,  since  many  programmers 
may  use  the  same  data  item  and  each  may  define  it  and  name  it 
differently.  The  analyst  responsible  for  system-wide  data 
specification  and  control  must  reconcile  data  documentation 
acquired  from  a  large  number  of  sources;  from  desiqn 
interrogation  or  program  analysis  on  each  proqram  that  uses  or 
makes  reference  to  a  data  element.  This  analyst,  unlike  the 
individual  programmer,  cannot  assess  the  differences  he  sees  from 
the  different  sources  and  resolve  conflicts  at  once.  To  resolve 
a  difference  in  interpretation  of  a  data  element  by  two  or  more 
programmers,  he  must  talk  to  them  and  assess  the  impact  of  a 
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chanqe  on  each  program  and  on 

Data  base  control 
data  documentation,  either  to 
documentation  or  to  announce 
con  f licts. 


the  overall  system. 

analysts  may  add  a  new  version  of 
combine  and  amplify  other 
the  existence  and  causes  of 


This  notion  of  standardized,  approved  data  items  brings 
up  another  consideration.  There  may  be  a  need  for  two  different 
kinds  of  documentation;  one  that  reflects  the  current  version  of 
the  program  and  one  that  reflects  the  approved  version.  During 
the  evolution  of  the  system  of  programs,  there  could  be  a 
requirement  for  documentation  of  a  program  as  it  exists  currently 
regardless  of  whether  it  still  has  bugs  in  it  and  whether  it  uses 
approved  data  definitions;  there  is  also  a  need  for  documentation 
of  the  design  of  the  program  using  standardized  data  definitions. 
Therefore,  it  seems  desirable  to  retain  some  degree  of 
duplication  throughout  the  evolution  of  the  object  system 
althouqh,  technically,  reconciliation  could  take  place  early  in 
the  project  life. 


At  first  glance,  it 
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For  another  example,  assume  this  hierarchical 
a  HOP  illustrated  in  Figure  5.  This  indicat 
taining  three  Load  Modules,  one  of  which  conta 
ceiures.  Further  assume  that  the  file  created  thro 
errogation  shows  this  structure  usina  the  indicated 
ociated  text  descriptions,  but  has  no  more 
ormation.  The  file  created  through  program  ana 
rse,  goes  into  a  finer  substructure  but  to  this  poi 
interrogation-acquired  file.  It  seems  certain 
ch  is  not  sufficient  to  conclude  that  text  accu 
cribe,  say.  Load  Module  1 
ule  1  as  it  has  been  coded. 
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LOAD  MODULE 


LOAD  MODULE 


LOAD  MODULE 
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PROCEDURE 

PROCEDURE 

PROCEDURE 
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Figure  5.  A  Job  Structure 
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DISSEMINATION  AND  ANALYSIS 


1.  Information  Retrieval.  ESDP  produces 
documentation — hard  copy  reports  and  machine  rea 
later  are  available  for  search  by  an  on- 
retrieval  system.  We  foresee  the  retrieval  sy 
either  for  short-reply  queries  or  occasional 
Otherwise,  conventional  reports  will  probably 
actual  balance  in  use  of  these  two  programs  wi 
preference  with  an  operational  system. 
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Perhaps  the  most  important  use  of  the  retrieval 
capability  will  be  to  assist  programmers  who  are  being 
interrogated  or  instructed.  In  either  case,  a  terminal  operator 
will  be  able  to  interrupt  the  programmed  conversation  to  ask  a 
question,  perhaps  to  check  the  specification  of  a  data  item  or  to 
review  an  earlier  entry  of  his  own.  Therefore,  one  of  the  key 
requirements  of  the  ESDP  retrieval  system  is  immediate 
responsiveness.  Another  is  that  the  IT?  system  operate  as  a 
subroutine  of  any  interrogation  or  instruction  program. 
Occasionally,  the  logical  niceties  of  the  IR  system  design  have 
to  be  subordinated  to  these  dominating  requirements. 
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In  pure  documentation  applications,  the  logical 
uirements  of  IR  are  rather  modest.  We  anticipate  that  most 
ries  would  call  out  a  program  element  or  data  item  by  name  and 
for  some  attribute  of  it  or,  at  most,  would  step  through  a 
work  of  program  elements,  using  the  IR  system  as  a  self- 
tructional  tool.  In  other  uses  of  ESDP,  though,  more 
borate  retrieval  logic  is  necessary.  When  using  the  system 
test  planning,  or  for  browsing  to  find  where  and  how  a 
posed  change  might  have  to  be  made,  we  would  expect  more  of  a 
uirement  than  for  single,  one-item  queries.  It  would  seem 
t  a  multifile  search  capability  is  clearly  indicated  in  this 
e  of  operation.  Multifile,  in  this  sense,  is  used  to  mean 
t  information  from  more  than  one  file  is  needed  to  evaluate  a 
rch  criterion.  Most  multifile  queries  could  be  accomplished 
ouqh  a  single  file  search  system,  with  enough  time  and 
ience,  but  lengthy  search  processes  are  disruptive  of  a  high 
ensity  browsing  operation. 


The  files 

to 

be  search 

Units 

of 

programm 

Units 

of 

data 

Units 

of 

instruct 

ed  consist 
ing 

ion 


of  descriptions 


of 


Program  text 


36 


Management  information 
Report  text  and  outlines 
Working  storage 
File  directories. 


The  first  three  represent  networks  and  hiera 
showing  structure  of  programs  and  data,  and  inte rconnection 
structures.  Each  element  of  information  will  have  a 
identifying  number,  called  an  information  element  number,  o 
(See  Section  II.  5) 
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A  table  of  TEN'S  will  be  stored  for  each  standard 
report  to  be  generated.  This  table  would  list  the  IEN's  to  be 
included  and  the  order  of  inclusion.  Each  information  element  in 
a  report  woull  have  an  element  number  of  the  same  form  as  used 
for  IEN's  but  meaningful  only  in  context  of  the  report.  For  each 
report  then,  there  would  be  a  table  of  equivalences  between 
report  IEN's  and  system  IEN's.  A  report  covering  inputs  to  all 
system  programs  might  renumber  IEN  1.2  for  program  15  and  assign 
a  report  IEN  of  3.7.15. 


Unplanned 
providing  a  list  of 


reports  can  be  generated 
IEN's  to  be  retrieved. 


at  any  time  by 


2.  Select ive  Dissemination.  We  repeat  here  an  earlier 
assertion:  selective  and  automatic  dissemination  of  design  notes 
and  chances  might  be  the  greatest  service  of  ESDP  during  the 
design  and  production  stages  of  a  programming  project.  Selective 
dissemination  [6]  is  not  a  new  concept  and  needs  little 
elaboration  here  except  to  point  out  that  we  consider  activity 
description  as  well  as  subject  descriptions  to  be  important  in 
dissemination  decisions.  This  means  that  a  change  to  IEN  1.2.3, 
regardless  of  the  subject  matter  of  the  change,  would  be 
disseminated  to  anyone  interested  in  IEN  1.2.3. 


3.  Instruction.  On  a  large 
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programming  project,  turnover  of 
of  people  from  many  different 
g  need  which  is  rarely  fulfilled. 
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A  computer  assisted  instruction  approach  has  been 
developed  which  makes  maximum  use  of  existing  program 
documentation  and  is  quite  flexible  in  regard  to  changes  in 
course  content.  The  basic  approach  is  to  use  CAINT  as  a  vehicle 
for  composing  CAI  courses.  A  course  author  converses  with  an 
ESDP  program  called  the  Instruction  Generator  and,  at  the 
completion  of  the  conversation,  an  instruction  course  written  in 
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the  CAINT  Executive  Language  is  produced.  During  the 
conversation,  the  author  can  easily  have  the  generator  extract 
whatever  information  he  wants  from  existing  documentation. 


The  generator  program  could  be 
either  computer  assisted  instruction 
programmed  instruction  courses. 


written 

courses 


to  produce 
or  printed. 


lisp  of  this  technique  enables  training  specialists 
compose  and  maintain  up  to  date,  self-instructional  material 
all  aspects  oc  the  object  system — whether  or  not  documentation 
complete.  New  personnel,  or  people  being  transferred  within 
project  can  learn  new  functions  and  bring  themselves  up  to  da 
at  relatively  little  cost  to  the  project. 
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c.  Having  most  management  data  in  machine  readable 
form  gives  the  opportunity  for  continual  review,  recomputation  of 
budgets,  schelules,  resource  allocations,  etc. 


Part  of  any  interrogation,  and  this  is  one  of  the 
strongest  reasons  for  having  design  interrogation  on  programs, 
should  cover  the  history,  the  status,  and  the  prospect  for  that 
program.  One  of  the  great  weaknesses  of  present  day  management 
reporting  systems  is  that  people  using  them  are  free  to  report 
the  same  information  over  and  over,  without  detection.  For 
example,  programmers  are  notorious  for  reporting  that  programs 
are  ninety  per  cent  debugged.  Relatively  simple  programs  can 
analyze  the  pattern  of  responses  to  management  queries  and  elicit 
the  necessary  explanations.  This  is  not  to  imply  that  a 
programmer  cannot  he  honestly  convinced,  on  each  of  five 
successive  weeks,  that  he  is  ninety  per  cent  done.  However, 
feeding  his  own  history  of  responses  back  to  him  and  asking  for 
his  interpretation  may  lead  him  to  recognize  that  his  estimates 
are  inaccurate,  and,  hopefully,  lead  him  to  improve  accuracy.  In 
general,  the  power  of  CAINT  can  and  should  be  used  to  elicit  from 
responders  the  nature  of  any  problem,  recommendations  for  its 
solution,  and  should  provide  reviews  of  previous  estimates  and 
problem  descriptions.  This  assures  that  information  on 
management  problems  is  written  down  and  is  actually  transmitted 
to  those  responsible.  It  also  assures  subordinates  that  their 
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problems  and  recommendations  are  reaching  their  managers. 

The  information  to  be  collected  relative  to  program 
management  is  variable,  as  is  program-descriptive  information, 
and  is  to  be  determined  by  the  using  organization.  The  following 
list,  though,  is  representative: 

Identification  of  objective  or  milestone  (e.g., 

completion  of  a  program,  a  test,  a  flow  chart 

.  ..) 


Time: 

estima 

te  to 

complete 

ta  sk 

actual 

time 

spent  to 

date 

review 

of  previous  estimates 

explanation  and  discussion  of  dis¬ 
crepancies  or  inconsistencies 

Manpower:  estimate  for  entire  task 

manpower  expended  to  date 

estimate  to  complete 

review  of  previous  estimates 

explanation  and  discussion  of  dis- 
discrepancies  or  inconsistencies. 

Related  milestones  or  tasks,  information  on  other 
tasks  dependent  upon  or  prereguisite  to  this  one 
which  might  be  affected  by  a  schedule  change,  or 
for  which  there  has  been  a  schedule  or  other 
change. 

Special  problems  being  faced,  decisions  needed 
from  higher  management,  recommendations  on  these 
problems,  constraints  imposed  by  management  or 
other  factors  such  as  overall  cost  limitations 
final  completion  deadlines,  etc. 

We  must  stress  that,  while  ESDP  provides  the 
communication  medium  for  the  exchange  of  this  information,  and 
while  it  can  efficiently  collect  far  more  detailed  managerial 
data  than  is  usual,  it  remains  with  the  project  managers  to  make 
the  best  use  of  this  information.  Certainly,  any  laxity  on  their 
part,  or  tendency  to  ignore  problems  reported  in  this  manner,  or 
tendency  not  to  take  seriously  ESDP  as  a  management  tool  will  be 
immediately  reflected  in  the  work  of  others,  possibly  extending 
into  technical  documentation. 
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IV 


EXTENSIONS  OF  THE  BASIC  SYSTEM 


1-  Introduction.  The  original  concept  of  ESDP  was  for  a  system 
that  would  enable  management  to  control  all  phases  of  the 
development,  operation  and  modification  of  computer  programs. 
Documentation  was  isolated  as  the  central  problem:  both  one  of 
the  largest  tasks  and  the  necessary  base  upon  which  other 
functions  might  be  based.  In  this  section  we  present  brief 
descriptions  of  additional  tasks  which  ESDP  might  be  extended  to 
perform  and  for  which  would  use  the  actual  documentation 
described  elsewhere,  or  the  methodology  of  ESDP  for  this 
performance. 

The  first  of  these  extends  documentation  from  programs 
and  data  to  program  tests,  then  extends  test  composition  and 
documentation  into  general  hypothesis  testing.  The  latter  is 
concerned  with  aiding  systems  management  personnel  to  study  the 
probable  effect  of  changes  in  system  parameters  or  logic. 

A  second  major  extension  is  into  active  computer 
assistance  in  programming,  itself,  rather  than  solely  into  the 
documentation  of  programs  and  their  designs. 

2.  Computer  Assisted  Test  Design  and  Hypothesis  Testing. 
Increasingly,  in  large  programming  systems,  the  programmer  is 
required  to  provide  formal  documentation  for  program  testing. 
Typically,  there  may  be  a  requirement  for  each  programmer  to 
submit  a  test  plan  for  his  individual  program  and  have  it 
approved  by  Systems  Management  before  he  begins  testing.  At  the 
conclusion  of  his  tests,  he  must  report  on  tests  actually 
conducted  and  the  results  thereof.  As  the  project  moves  into  the 
system,  or  assembly,  test  phase  even  more  complex  test  plans  are 
reg  uired . 

a.  Nature  of  Program  Testing 

Testing  and  debugging  are  complex,  ill-defined 
activities.  In  a  large  system  it  is  totally  impractical  to  try 
each  possible  input  that  a  program  might  someday  have  to  process. 
Since  this  is  so,  after  any  test  period  there  might  be  a  program 
path  or  combination  of  circumstances  that  has  remained  untested 
but  would  result  in  an  error  if  executed.  One  alternative  is  to 
systematically  test  each  thread  of  a  program  without  attempting 
to  try  each  possible  combination  of  subthreads. 

As  long  as  a  test  designer  is  going  to  be  selective 
rather  than  exhaustive  he  needs  assistance  in  selecting  paths  to 
be  tried.  Such  assistance  should  be  in  the  form  of  help  in 
determining  which  control  decisions  are  independent  of  each  other 
(to  reduce  redundant  testing),  what  paths  would  be  followed  if 
input  and  data  base  values  are  given,  and  what  data  values  are 
required  to  reach  a  given  point  in  a  program.  In  the  early 
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stages,  testinq  and  debugging  do  not  differ.  We  define  as  the 
difference  that  debugging  is  a  process  by  which  a  programmer 
convinces  himself  that  his  program  "works”  and  testing  is  a 
process  by  which  he  formally  demonstrates  the  acceptability  of 
the  program  to  another  person. 

During  debugging,  many  errors  are  detected  and  changes 
made.  Hence,  debugging  operations  are  set  up  to  assist  the 
programmer  in  the  rapid  detection  and  correction  of  errors. 
During  testing  this  may  happen,  but  the  programmer  does  not 
expect  many  errors  or,  presumably,  he  would  not  have  entered  the 
test  phrase. 

In  both  debugging  and  testing  of  individual  programs, 
emphasis  is  on  systematic  testing  of  paths  within  a  program, 
usually  based  on  artificially  created  test  inputs,  sometimes 
anachronistically  called  "test  decks."  In  the  later  stages  of 
program  testing--system  or  assembly  testing — whenever  larqe 
groups  of  programs  are  run  together,  testing  is  more  and  more 
based  on  test  cases  which  are  defined  in  terms  of  overall  system 
conditions  or  situations,  rather  than  in  terms  of  execution 
sequences.  In  other  words,  a  system  test  might  be  set  up  on  the 
basis  of  an  externally  meaningful  test  case  (e.g. ,  in  an  air 
traffic  control  system,  conditions  of  runway  usage,  wind, 
weather,  and  traffic  load  may  be  tested,  rather  than  an  explicit 
test  of  how  programs  A,  B,  and  C  interrelate) . 

We  have,  then,  what  amounts  to  a  continuum  of  test 
situations,  ranging  from  the  typical  debugging  situation  of 
testing  a  small  segment  of  code  by  itself,  through  testinq  of 
interactions  among  programs,  to  testing  a  program  system's 
ability  to  perform  properly  on  an  externally-defined  condition. 

To  plan  tests  at  the  detailed  end  of  this  spectrum  the 
programmer  needs  such  information  as: 

data  items  in  use 

initial  values  needed  for  a  test 

output  items  computed,  switches  set,  etc., 

and  these  are  usually  readily  identifiable  from  a  glance  at  the 
source  coding  of  a  program. 

As  the  programmer  begins  to  test  branching  and 
interaction  among  components  of  his  own  program,  he  is  dealing 
with  much  larger  sets  of  code  and  with  more  complex  interactions, 
particularly  with  interactions  not  explicitly  recognizable  from 
the  text.  It  is  in  this  area  that  some  of  the  controversy  over 
the  value  of  on-line  debugging  arises,  proponents  arguing  that  a 
programmer  must  spend  a  large  amount  of  time  relearning  his  own 
program  after  each  debug  run  because  he  cannot  retain  these 
complex  interactions  in  his  mind  for  long.  Increasingly,  the 
programmer  is  concerned  with  such  questions  as,  "What  will  happen 
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"What  value  of  X  will  cause  a 
"What  data  items  are  used  to  compute 


For  both  individual  program  testing  and  for  component 
testing,  the  programmer  must  find  the  answers  to  such  questions 
as,  "Under  what  circumstances  will  the  program  branch  from 

component  Y  to  component  Z?"  "If  input  item  X  =  _ ,  what  thread 

will  the  program  follow?"  "In  what  form  is  data  passed/received 
between  proarams  A  and  B?" 

Finally,  at  the  highest  level  of  testinq,  the  test 
designer  is  concerned  with  such  questions  as  "What  happens  when 
the  operator  hits  the  DELETE  key  after  entering  a  query?"  "How 
will  the  system  react  to  an  overload  situation?"  "What  is  the 
total  delay  time  between  the  arrival  of  a  given  input  and  its 
subsequent  display  on  a  console?"  "What  happens  if  a  customer’s 
balance  goes  to  zero?" 
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By  extending  ESDP  slightly  we  can  encompass  the 
preparation  of  test  documentation  within  ESDP  and  also  provide 
means  for  automatic  creation  of  "test  decks"  or  program  test 
data.  Preparation  of  test  data  is  not  a  difficult  conceptual 
problem  but  it  is  a  practical,  clerical  problem  of  some  magnitude 
which  can  be  alleviated  by  a  well-desiqned  lanquage  specific  to 
the  function,  or,  as  proposed  here,  by  use  of  CAINT  to  elicit 
requirements  and  produce  data-qenerat ina  code. 

The  expansion  necessary,  in  the  programming  area,  would 
be  to  increase  the  amount  of  detail  acquired  by  program  analysis, 
particularly  in  classifying  the  way  in  which  a  data  label  is  used 
in  a  source  code  UOP,  and  somewhat  modifying  the  interrogation  to 
more  fully  describe  branching  decisions.  The  symbolic  test  data 
composition  program  would  be  similar  to  a  portion  of  the  Lincoln 
Checker,  [7]  part  of  the  utility  system  developed  for  use  in 
SAGE.  In  addition  to  these  programming  steps,  considerable  work 
needs  to  be  done  to  learn  how  to  make  effective  use  of  such 
facilities  and,  possibly,  how  to  assess  analytically  the  validity 
of  a  test  plan,  in  terms  of  completeness,  redundancy,  or 
efficient  use  of  resources. 
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b.  Hypothesis  Testing 


Hypothesis  testing  is  an  extension  of  these  concepts. 
In  hypothesis  testing  we  assume  we  have  an  operating  computer 
system  which  we  wish  to  change--by  modifying  equipment,  input 
rate,  load,  legal  input  values,  or  processing  to  be  performed  or 
decision  rules  to  be  used.  Basically,  we  wish  to  answer  the 
question,  "What  would  happen  to  the  existing  system  if  the 
following  change  were  made?”  or  "How  will 
the  following  change?"  We  will,  then,  be 
configuration,  file  content,  or  program 
through  an  existing,  presumably  correctly 
find  out  what  would  happen  under  the 
components  have  been  changed  in  a  specified  way. 
would  be  trying  to  find  out  what  changes  are  needed 
components,  given  a  change  in  one. 
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capability  would  enable  a  system  user, 
in  the  operational  or  application  area 
rather  than  in  programming  itself,  to 
of  the  system  and  to  a  large  extent,  to 
n  decisions  on  whether  an  existing  system 
to  adapt  to  a  new  requirement,  how 
be,  etc.  In  a  system  of  sufficient 

h  may  be  the  only  way  these  questions  can 
t  be  that  a  joint  team  of  programmers, 
ystem  users  should  interrogate  the  system 
requirements.  Thus,  hypothesis  testing 
he  original  problem  upon  which  ESDP  was 
the  orderly  evolution  of  a  programming 
for  its  use,  or  the  environment  unler 
es. 


Planning  a  Test 


A  test  plan  for  a  computer  program  or  program  module 
is,  or  we  believe  should  be,  a  plan  for  a  series  of  program  runs 
which  when  carried  out  will  demonstrate  to  a  disinterested 

observer  that  the  program  performs  according  to  specifications. 
A  test  plan  requires  both  a  systematic  plan  for  testinq  portions 
of  the  program  and  a  set  of  test  cases  that  will  force  the 

program  to  operate  as  planned.  Not  all  programs  are  tested  in 
all  combinations  of  paths  or  conditions.  The  completeness  of  a 
test  plan  varies  with  the  nature  of  the  program 
Often,  a  test  planner,  while  realizing  he  i 
testing  a  program,  has  no  way  of  knowing  exactly  what  portions  he 
is  testing.  Thus,  areas  left  untested  are  "selected"  at 
Areas  that  are  tested  may  be  overtested, 

applying  ESDP  to  program  test  planning  is  to  give  the  test 

designer  control  over  those  variables. 
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In  order  to  plan  a  test,  the  designer  must  be  able  to 
isolate  and  describe  subsets  of  the  program  to  be  tested  in  each 
trial.  We  expect  the  ESDP  documentation  and  approach  to  proaram 
organization  to  be  of  great  help  here.  There  is  more  than  one 
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way  to  break  down  a  program  but,  so  long  as  the  various 
partitions  can  be  described  in  terms  of  UOP's,  ESDP  allows  for 
individual  variation.  Two  major  variations  are:  partitioning  a 
program  in  terms  of  what  it  accomplishes  (e.g.,  adding  a  new 
employee  record  to  the  personnel  file)  or  in  terms  of  the 
sequence  of  execution  of  UOP's  (recall  that  a  single  command  or 
program  statement  can  be  a  UOP).  The  latter  approach  to  testing, 
systematically  probing  possible  execution  sequences  is  certainly 
well  adapted  to  ESDP.  The  other  approach — defining  an  execution 
sequence  in  terms  of  accomplishment — can  be  used  as  the  basis  for 
testing,  with  the  program  region  so  defined  being  translatable 
into  UOP’s  by  use  of  the  ESDP  retrieval  system.  This,  in  turn, 
can  lead  a  search  from  operational  terms  to  UOP's  to  execution 
sequences.  The  ESDP  retrieval  system  is  also  capable  of 
retrieving  and  displaying  a  table  of  information  on  control 
variables  for  any  defined  path.  This  information  would  become 
the  basis  upon  which  the  test  designer  creates  his  trial  data  or 
test  cases. 


The  generation  of  test  cases,  particularly  if  it  is  a 
matter  of  initializing  a  set  of  core-stored  variables  (as  opposed 
to  creatinq  and  storing  a  data  set  on  a  disk)  is  not  too 
difficult  but  is  time-consuming  and  subject  to  human  error.  The 
technique  used  in  instruction,  of  having  a  CAINT  proqram  generate 
PL/I  code,  can  be  used  to  assist  test-case  generation.  The  kind 
of  proqram  to  be  produced  would  be  a  relatively  simple  one  that 
sets  a  number  of  data  variables  to  values  specified  by  the  test 
desiqner.  His  specification  would  be  entered  via  a  CAINT  proqram 
which  would  provide  him  the  information  he  needs  on  paths  and 
UOP's,  elicit  a  test  specification,  and  check  the  validity  of 
test  values. 


This  is  one  of  the  almost  hidden  problems  of  proqram 
testing.  Given  that  a  programmer  intends  to  test  the  path  from 
UOP  A  to  B  to  C,  and  he  thinks  he  knows  what  test  values  he  must 
use  to  do  so,  did  he,  in  fact,  compose  a  correct  test  case? 
Using  CAINT,  each  test  value  can  be  checked  against  the 
specification  for  the  variable,  and  all  test  cases  catalogued. 
After  the  program  has  been  run,  the  values  of  certain  variables 
can  be  copied  and  recorded  with  other  test  information  to 
completely  document  the  test. 
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Returning  to  the  mechanics,  a  test  case  interrogation 
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to  initialize  the  stated 
object  system  program 


before  the  test 
to  maintain  the 
it  could  also  prepare  a  small  program,  to  be  inserted  into 
t  module,  that  would  record  the  values  of  stated  variables 
test.  In  this  way,  both  interrogation  on  input  and 
nq  of  results  would  be  automatic,  savinq  programmer  time, 
ing  reliability,  and  increasing  credibility  of  the  test 
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The  design  of  a  test  would  probably  proceed  somewhat 
along  these  lines.  The  test  designer  has  a  fairly  good  idea  of 
the  structure  of  the  module  he  is  to  test  and  of  the  input.-to- 
output  transformation  it  mates.  The  test  designer  is  not  always 
the  programmer,  so  his  familiarity  may  have  to  be  acquired  and  he 
may  make  heavy  use  of  ESDP’s  retrieval  and  instructional 
facilities  in  the  process.  Presumably,  he  will  then  make  a 
decision  whether  to  test  on  the  basis  of  systematic  forcing  of 
threads  in  the  program  or  testing  in  terms  of  accomplishment  or 
function,  which  would  require  the  determination  of  paths 
involved. 

To  force  a  path — i.e.,  to  get  the  program  to  execute  a 
specified  set  of  UOP*s  in  a  specified  sequence,  the  tester  needs 
to  know  what  data  variables  are  used  in  branching  decisions,  what 
variables  are  used  to  compute  control  items,  and  what  input  or 
output  operations  are  performed.  He  comDiles,  for  each  path  or 
thread,  a  set  of  initial  conditions  and  a  list  of  items  that  are 
changing  along  the  path  and,  of  those,  which  ones  he  would  want 
recorded  as  proof  of  the  text.  All  this  information  can  be 
recorded  with  ESDP's  facilities  and  to  it  should  be  added  some 
narrative  on  the  purpose  or  meaning  of  the  test. 

d.  Test  Priorities 


It  is  not  necessary  that  all  trials  be  completed  before 
a  program  can  be  used.  It  is  often  necessary  or  at  least  highly 
desirable  to  prove  out  one  portion  of  a  program  and  use  that  to 
help  prove  out  another  portion.  Since  not  all  paths  of  all 
programs  will  be  tested,  it  is  necessary  to  devise  some  priority 
ordering  scheme  for  paths  and  regions.  This  priority  is  not 
necessarily  inherent  in  the  program  but  may  be  a  function,  as 
well,  of  the  program  structure,  the  test  conditions,  and  the 
immediate  need  for  the  program  either  operationally  or  to  support 
other  tests. 


Criteria  for  priority  ordering  of  paths  and  regions 
should  be  established  by  the  test  designer  and  thereafter  used  by 
the  test  assistance  programs  to  help  him  keep  track  of  what  he 
has  already  done  and  needs  to  do  next  and  the  relative  importance 
of  paths  yet  to  be  tested. 
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An  example  of  the 
establishing  priori  ties  is  this, 
the  program  which  represents 
sequence  of  UOP's  to  be  executed 

error-free  situation.  If  he  can  get  that  much  tested,  he  can 
his  knowledge  that  it  runs  correctly  to  help  debug  or  test  ot. 
portions  and  can  even  allow  this  program  to  be  used  in  limi 
assembly  testing  while  he  completes  testing  of  the  more  obsc 
paths.  Even  to  test  the  "main  trunk"  he  may  find  it  desirable 
pre-test  certain  frequently-used  subroutines.  Thus,  th 
subroutines  become  first  in  priority.  Next  comes  the  m 
execution  path  which  establishes  that  the  main  program  cycles 
provides  output  for  use  by  connected  programs.  Finally,  ot 
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paths  than  the  main  one  are  attacked.  These  may  be  further 
classified  according  to  probability  of  occurrence,  support  to 
debugging  and  testing,  interface  with  other  programs,  etc. 


At  all  times  during  test  planning  the  assistance 
program  keeps  track  of  what  trials  have  been  generated,  what 
paths  or  regions  are  used,  and  what  test  data  is  used.  This 
information,  together  with  the  assistance  program's  knowledge  of 
the  structure  of  the  test  program  and  of  the  priorities  assigned 
to  components  of  it,  enables  recommendations  to  be  made  to  the 
test  designer  on  what  is  the  most  fruitful  trial  to  begin  next. 


e.  Summary 

Assistance  can  be  provided  to  test  designers,  through 
ESDP  or  extensions  of  the  programs  specified  to  date,  in  the 
following  ways: 

(1)  Retrieval  and  display  of  information  on 
program  structure  and  data  usage,  used  to  acquire  an 
understanding  of  the  program  and  to  select  paths  and  regions  for 
trials. 


(2)  Assistance  in  tracing  execution  paths  as  a 
function  of  some  criterion,  e.  g.  ,  paths  that  might,  be  followed  if 
X  =1.  While  this  task  might  ultimately  be  mechanized,  it  would 
probably  be  a  man-machine  function  at  first. 

(3)  Acquisition,  storage  and  retrieval  of  path 
and  region  priority  information.  The  object  is  to  allow  each 
designer  full  freedom  to  assign  priorities  (or  not  use  the 
facilities)  as  he  sees  fit,  yet  make  use  of  the  program  as  easy 
as  possible. 


(4)  Active  assistance  by  the  program  in 
suggesting  what  paths  or  regions  should  next  be  considered  for  a 
test. 


(5)  Retrieval  and  display  of  information  relative 
to  data  values  needed  to  proceed  along  a  given  path,  into  a 
region,  or  to  accomplish  a  stated  objective. 

(6)  Computer  assistance  in  generating  test  cases 
by  initializing  variables  to  appropriate  values. 

(7)  Computer  assistance  in  recording  data  values 
during  or  after  a  test,  and,  in  general,  in  documenting  test 
results. 


3.  Computer  Assisted  Programming.  Under  ESDP  we  have  developed 
techniques  for  describing  program  and  data  structures,  for 
eliciting  information  from  a' programmer  about  proposed  programs 
and  data  files  and  for  analyzing  programs  once  written.  From 
these  analytic  and  elicitation  programs  documentation  of  program 
systems  is  created.  Also  as  part  of  ESDP,  a  program  has  been 
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produced  which  converses  with  a  program  author  and  produces  an 
output  which  is  a  syntactically  correct  PL/I  program  to  be  used 
for  instructional  purposes.  These  techniques  can  be  combined  and 
generalized  to  produce  a  conversational  program  which  can  carry 
on  an  English-language  conversation  with  a  programmer  and  produce 
programs  of  far  more  general  structure  than  that  of  the 
instructional  programs  generated  so  far. 


The 

documentation 
design  and, 
more  detailed 
may  request 
which  is  real 
interrogation 


approach  would  be  somewhat  the  same  as  now  used  for 
.  The  programmer  is  first  interrogated  on  his 
in  succeeding  interrogations,  he  enters  increasingly 
design  information.  At  any  time,  the  programmer 
to  be  switched  into  the  program  composition  mode 
ly  nothing  more  than  a  far  more  detailed  design 


The  existence  of  design  information,  written  by  the 
programmer,  provides  the  ESDP  system  with  information  that  can  be 
used  to  search  a  library  of  available  routines  and  one  of  known 
program  models.  From  either  or  both  these  libraries,  the  proqram 
can  retrieve  information  on  which  to  base  more  detailed 
interrogations  of  the  programmer.  For  example,  if  the  design 
information  specifies  that  a  sort  is  to  be  performed,  the  CEL 
program  can  retrieve  information  about  sort  programs  from  its 
library.  It  detects  the  relevance  of  sort  programs  by  a  key  word 
analysis  of  the  programmer's  responses  to  documentation 
questions.  With  the  additional  knowledge,  it  retrieves,  it  can 
make  further  checks  against  the  parameters  of  existing  program 
modules.  If,  for  example,  it  discovers  that  the  programmer 
wishes  to  sort  a  table  that  is  stored  in  core,  the  interrogation 
program  will  try  to  find  such  an  internal  sort  program  in  its 
library.  If  it  does,  little  more  may  be  needed  than  to  evaluate 
a  calling  sequence.  If  no  program  exactly  fits,  one  can  be 
composed  either  in  programming  language  statements  or  in  terms  of 
smaller  modules  or  macro-instructions.  The  less  prior 
information  that  is  available,  clearly,  the  less  the  computer  is 
able  to  help  write  the  program.  Ultimately,  if  the  programmer 
wishes  to  compose  a  program  bearing  no  detectable  relationship  to 
any  program  known  to  the  system,  he  must  write  it  more  or  less  in 
the  normal  manner.  Computer  assistance  can  still  be  used, 
however.  His  statements  can  be  syntactically  checked  as  they  are 
entered  and  documentation,  both  from  interrogation  and  program 
analysis,  can  be  built  up  as  the  program  is  composed.  This  qives 
the  programmer  instant  review  capability,  always  with  fairly 
complete  documentation,  on  all  completed  portions  of  the  program. 

The  greatest  value  to  be  derived  from  this  system  would 
come  when  there  is  prior  information  about  the  type  program  to  be 
written.  If  not  available  as  parameter  descriptions  for  an 
existing  proqram,  this  information  might  be  largely  in  the  form 
of  ohject  models,  or  generalized  program  specifications,  to  be 
detailed  by  a  programmer. 


The  object  model  is  a  set  of  information  descriptive  of 
a  wide  class  of  object  programs,  such  as  sort  programs  or 
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instructional  programs.  The  model  gives  the  general  structure 
and  limitations  and  names  elements  that  must  be  specified  for  any 
particular  member  of  the  class,  or  implementation.  In  the 
instruction  program  class,  this  includes  questions,  anticipated 
answers,  and  branching  commands.  The  Generator  program  operates 
through  the  object  model,  acquiring  from  that  model  both  the 
questions  it  needs  to  ask  the  program  designer  and  the 
information  it  needs  to  analyze  his  answers. 

Use  of  the  object  model  in  conjunction  with  a 
generalized  Generator  (which,  recall,  is  a  CEL  interrogation 
proqram)  is  analogous  to  an  information  retrieval  program  which 
makes  use  of  file  directories  or  format  tables.  By  using  tables 
which  describe  the  data  files  handled  by  the  retrieval  system, 
the  retrieval  programs  can  be  made  quite  general.  They  always 
refer  to  the  directory  to  determine  how  to  interpret  any  file. 
Hence,  it  is  not  necessary  to  modify  a  program  when  changing  the 
structure  of  a  file.  It  is  only  necessary  to  change  the 
directory's  description  of  the  file  and  the  program  adapts  itself 
to  the  new  structure.  Similarly,  the  Generator  will  perform  the 
functions  specified  by  the  object  model  so  that  the  Generator 
need  not  be  modified  to  change  from  producing  one  type  program  to 
another.  Probably,  the  more  experienced  programmers  would 
provide  the  models  and  less  experienced  programmers  would  add  the 
detail.  Early  in  the  development  of  a  large  system,  the  senior 
designers  would  contribute  specifications  in  the  form  of 
documentation  and  object.  models.  These  models  can  be 
successively  more  detailed  as  they  are  passed  down  the  chain  of 
command  to  less  experienced  people.  The  major  difference  in 
approach  here  over  what  is  proposed  for  documentation  purposes  is 
that  at  the  design  documentation  level,  designers  supply  not  only 
known  information  but  describe  what  additional  information  has  to 
be  provided  in  order  to  proceed  to  the  next  level  of  detail. 

To  implement,  this  system,  a  conversational  program 
would  be  required  whose  inputs  are  an  object  model  and  a  set  of 
user  responses  entered  through  a  remote  terminal.  The  output 
would  be  a  computer  program  in  a  specified  programming  language, 
such  as  PL/I,  ready  for  compilation  and  guaranteed  to  compile. 
There  will  be  no  syntax  errors  in  the  object  code.  Clearly, 
whether  or  not  there  are  logical  errors  depends,  as  usual,  on  the 
des igner. 


A  simplified,  preliminary  model  exists  and  is  at  this 
date  partially  operational.  This  is  the  Instruction  Generator 
previously  mentioned  (Section  1.4)  which  has  as  its  sole  aim  the 
generation  of  instructional  (CAI)  programs.  Such  programs  have  a 
far  simpler  structure  than  most  computer  programs.  Still,  the 
concept  is  basically  the  same,  and  the  programming  techniques 
used  to  generate  object  code  from  English  language  conversation 
are  directly  applicable  to  the  larger,  more  general  problem. 

The  Generator  would  enable  a  user  who  is  not  trained  in 
computer  programming  to  write  programs  with  relative  ease.  Use 
of  the  Generator  could  also  increase  the  effectiveness  to 
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technical  personnel  who  need  programs  to  support  their  o 
Examples  of  such  people  are  engineers  or  scienti 
professional  programmers,  who  nonetheless  need  data  p 
services.  Other  examples  are  professional  computer  pr 


who  must  cope  with  the  mysteries  of  a 
order  to  accomplish  their  own  tasks, 
an  operating  system  in  the  same  sense 
of  FORTRAN. 
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